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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



The present document is part of a set of TSs which describe the requirements and information necessary for the 
standardised charging of 3G system. 
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Scope 



The present document describes the principles of charging and billing for the provision of service and services by a 
3G-system. 

The present document elaborates on the charging requirements described in the Charging Principles in 3GPP 
TS 22. 101 [1]. It allows the generation of accurate charging information to be used in the commercial and contractual 
relationships between the parties concerned. The present document is not intended to duplicate existing standards or 
standards being developed by other groups on these topics, and references these where appropriate. 

The Charging Data Records (CDRs) generated by the network elements of the 3G network, are required for a number of 
telecom management activities including, but not limited to, the following: 

the billing of home subscribers, either directly or via service providers, for network utilisation charges; 

the settlement of accounts for traffic carried or services performed by fixed network operators and other 
operators; 

the settlement of accounts with other PLMNs for roaming traffic via the transferred account procedure; 

statistical analysis of service usage; 

as archival information in dealing with customer service and billing complaints. 

In addition to the information collected from network elements, network management functions are required for the 
administration of charging data. 

The present document is part of a series of documents specifying charging functionality in UMTS networks. The 
UMTS charging architecture and principles are specified in the present document which provides an umbrella for other 
charging documents that specify the structure and content of the CDRs and the interface protocol that is used to transfer 
them to the collecting node. The CDRs used in the Circuit Switched (CS) domain are specified in document3GPP 
TS 32.205 [5]. The CDRs content and transport within the PS domain are described in3GPP TS 32.215 [6] document, 
while CDRs used for application services are defined in document3GPP TS 32.235 [17]. 

The relationship among these charging specifications is illustrated in figure 1.1. 
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Figure 1.1: Charging Documents Structure 

For the purpose of the present document, the charging data is considered to be generated and collected by charging 
functions in the network elements. 

Charging data fields are collected and CDRs generated by the network elements for transfer to the billing system. For 
the packet switched domain, the CDRs are first sent to the Charging Gateway Function (CGF) for storage and further 
processing. The CGF may be a distinct network element or may be integrated into the packet domain network elements 
themselves. 
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The objectives of the present document are: 

to describe principles of charging in a 3G network; 

to provide a description of the charging architecture; and 

to provide the descriptions of events and triggers for the generation of Charging Data Records (CDRs). 

2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TS 22.101: "Service aspects; Service Principles". 
[2] 3GPP TS 22.115 "Service aspects; Charging and bilHng". 

[3] 3GPP TS 32.101: "Telecommunication management; Principles and high level requirements". 

[4] 3GPP TS 32.102: "Telecommunication management; Architecture". 

[5] 3GPP TS 32.205: "Telecommunication management; Charging management; Charging data 

description for the Circuit Switched (CS) domain". 

[6] 3GPP TS 32.215: "Telecommunication management; Charging management; Charging data 

description for the Packet Switched (PS) domain". 

[7] 3GPP TS 22.024: "Description of Charge Advice Information (CAI)" . 

[8] 3GPP TS 22.086: "Advice of Charge (AoC) supplementary services; Stage 1". 

[9] 3GPP TS 24.008: "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3". 

[10] 3GPP TR 23.815: "Telecommunication management; Charging management; Online Charging 

System (OCS) architecture study". 

[II] Void. 

[12] 3GPP TS 29.060: "General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) 

across the Gn and Gp interface". 

[13] 3GPP TS 23.078: "Customised Apphcations for Mobile network Enhanced Logic (CAMEL); 

Stage 2". 

[14] 3GPP TS 29.078: "Customised Applications for Mobile network Enhanced Logic (CAMEL); 

CAMEL Apphcation Part (CAP) specification". 

[15] IETF RFC 959 (1985): "File Transfer Protocol"; J. Postel, J. Reynolds, ISI. 

[16] IETF RFC 783 (1981): "TFTP Protocol (revision 2)"; K.R. SoUins MIT. 

[17] 3GPP TS 32.235: "Telecommunication management; Charging management; Charging data 

description for application services". 

[18] ITU-T Recommendation D.93: "Charging and accounting in the international land mobile 

telephone service (provided via cellular radio systems)". 
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[19] 3GPP TS 23.140: "Multimedia Messaging Service (MMS); Functional description; Stage 2". 

[20] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[21] 3GPP TS 23.002: "Network architecture". 

[22] 3GPP TS 23.009: "Handover procedures". 

[23] 3GPP TS 24.086: "Advice of Charge (AoC) Supplementary Service; Stage 3". 

[24] 3GPP TS 32.225: " Telecommunications management; Charging management; Charging Data 

Description for IP Multimedia Subsystem". 

[25] 3GPP TS 23.060: "General Packet Radio Service (GPRS); Service description; Stage 2". 

3 Definitions, abbreviations and symbols 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 21.905 [20] and the following apply: 

(GSM only): qualifier indicating that this subclause or paragraph applies only to a GSM system 
For multi-system cases this is determined by the current serving radio access network. 

(UMTS only): qualifier indicating that this subclause or paragraph applies only to a UMTS system 
For multi-system cases this is determined by the current serving radio access network. 

real time: real time charging and billing information is to be generated, processed, and transported to a desired 
conclusion in less than 1 s 

near real time: near real time charging and billing information is to be generated, processed, and transported to a 
desired conclusion in less than 1 minute 

2G- / 3G-: prefixes 2G- and 3G- refers to functionaUty that supports only GSM or UMTS, respectively, e.g. 2G-SGSN 

refers only to the GSM functionality of an SGSN 

When the prefix is omitted, reference is made independently from the GSM or UMTS functionality. 

in GSM,...: qualifier indicating that this paragraph applies only to GSM System 
For multi system cases this is determined by the current serving radio access network. 

in UMTS,...: qualifier indicating that this paragraph applies only to UMTS System 
For multi system cases this is determined by the current serving radio access network. 

accounting meter record: record containing one or more counters employed to register the usage of resources en 

masse 

Includes simple event counters and/ or cumulative call second counters. 

accounting: process of apportioning charges between the Home Environment, Serving Network and User 

advice of charge: real-time display of the network utilisation charges incurred by the Mobile Station 

The charges are displayed in the form of charging units. If a unit price is stored by the MS then the display may also 

include the equivalent charge in the home currency. 

aoc service: combination of one or more services, both basic and supplementary, together with a number of other 
charging relevant parameters to define a customised service for the purpose of advice of charge 

billing: function whereby CDRs generated by the charging function are transformed into bills requiring payment 

CAMEL: network feature that provides the mechanisms to support operator specific services even when roaming 
outside HPLMN 

CAMEL subscription information: identifies a subscriber as having CAMEL services 
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Charging Data Record (CDR): record generated by a network element for the purpose of billing a subscriber for the 
provided service 

It includes fields identifying the user, the session and the network elements as well as information on the network 
resources and services used to support a subscriber session. In the traditional circuit domain, CDR has been used to 
denote "Call Detail Record", which is subsumed by "Charging Data Record" hereafter. 

chargeable event: activity utilising telecommunications network infrastructure and related services for user to user 
communication (e.g. a single call, a data communication session or a short message), or for user to network 
communication (e.g. service profile administration), or for inter-network communication (e.g. transferring calls, 
signalling, or short messages), or for mobility (e.g. roaming or inter-system handover), which the network operator 
wants to charge for 

charged party: user involved in a chargeable event who has to pay parts or the whole charges of the chargeable event, 
or a third party paying the charges caused by one or all users involved in the chargeable event, or a network operator 

charging: function whereby information related to a chargeable event is formatted and transferred in order to make it 
possible to determine usage for which the charged party may be billed 

circuit switched domain: domain within UMTS in which information is transferred in circuit mode 
domain: part of a communication network that provides services using a certain technology 

GPRS: Packet Services for GSM and UMTS systems 

inter-system change: change of radio access between different radio access technologies such as GSM and UMTS 

observed IMEI ticket: record used to describe an EIR relevant event e.g. a blacklisted IMEI 

packet switched domain: domain within UMTS in which data is transferred in packet mode 

settlement: payment of amounts resulting from the accounting process 

short time: time, typically in number of minutes, to perform the offline mechanism used for accounting 

successful transaction: circuit connection that reaches the communication or data transfer phase e.g. the "answered" 

state for speech connections 

A packet connection that achieves completed data transfer. All other connection attempts are regarded as unsuccessful. 

tariff period: part of one (calendar) day during which a particular tariff is applied 

Defined by the time at which the period commences (the switch-over time) and the tariff to be applied after switch-over. 

tariff: set of parameters defining the network utilisation charges for the use of a particular service 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 



3G 


3"* Generation 


3GPP 


3G Partnership Project 


AoC 


Advice of Charge 


APN 


Access Point Name 


BMD 


Billing Mediation Device 


BS 


BilHng System 


CAI 


Charge Advice Information 


CAMEL 


Customised Applications for Mobile network Enhanced Logic 


CDR 


Charging Data Record 


CG 


Charging Gateway 


CGF 


Charging Gateway Function 


CI 


Cell Identity 


CS 


Circuit Switched 


CUG 


Closed User Group 


DP 


Detection Point 


DRP 


Data Record Packet 


EDP 


Event Detection Point 


EIR 


Equipment Identity Register 
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EM Element Management 

ETSI European Telecommunications Standards Institute 

FCI Furnish Charging Information 

FT AM File Transfer, Access and Management 

FTP File Transfer Protocol 

G-CDR GGSN generated- CDR 

GGSN Gateway GPRS Service Node 

GMLC Gateway Mobile Location Center 

GMSC Gateway MSC 

GPRS General Packet Radio Service 

gsmSCF GSM Service Control Function 

gsmSSF GSM Service Switching Function 

GSN GPRS Support Node (either SGSN or GGSN) 

GTP GPRS Tunnelling Protocol 

HLR Home Location Register 

HPLMN Home PLMN 

HSCSD High Speed Circuit Switched Data 

ICS Implementation Conformance Statements 

IE Information Element 

IHOSS:OSP Internet Hosted Octet Stream Service: Octet Stream Protocol 

IMEI International Mobile Equipment Identity 

IMSI International Mobile Subscriber Identity 

lOI Inter Operator Identification 

IP Internet Protocol 

ISDN Integrated Services Digital Network 

ISP Internal Standardized Profiles 

Itf Interface 

ITU-T International Telecommunication Union - Telecommunications Standardisation Sector 

LAC Location Area Code 

LCS Location Services 

M-CDR Mobility Management generated-Charging Data Record 

ME Mobile Equipment 

MGW Media Gateway 

MMS Multimedia Messaging Service 

MMSE Multimedia Messaging Service Environment 

MOC Mobile Originated Call (attempt) 

MS Mobile Station 

MSC Mobile Services Switching Centre 

MSISDN Mobile Station ISDN number 

MSRN Mobile Station Roaming Number 

MTC Mobile Terminated Call (attempt) 

NE Network Element 

NM Network Management 

NMC Network Management Centre 

NSS Network and Switching Subsystem 

OA&M Operation, Administration and Maintenance 

OACSU Off air call set-up 

O-CSI Originating CAMEL Subscription Information 

OMC Operations and Maintenance Centre 

PBX Private Branch eXchange 

PDN Packet Data Network 

PDP Packet Data Protocol, e.g. IP 

PDU Packet Data Unit 

PLMN Public Land Mobile Network 

PPP Point-to-Point Protocol 

PPS Post-processing system 

PS Packet-Switched 

PSPDN Packet-Switched PubUc Data Network 

PT Protocol Type (Field in GTP' header) 

QoS Quality of Service 

RAB Radio Access Bearer 

RAC Routing Area Code 
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RAN Radio Access Network 

RANAP Radio Access Network Application Part 

RNC Radio Network Controller 

SAC Service Area Code 

S-CDR SGSN (PDP context) generated - CDR 

SCF Service Control Function 

SCI Subscriber Controlled (MMI) Input 

SCS System Conformance Statement 

SGSN Serving GPRS Service Node 

SMF System Management Function 

SMS Short Message Service 

SS7 Signalling System No. 7 

S-SMO-CDR SGSN delivered Short message Mobile Originated - CDR 

S-SMT-CDR SGSN delivered Short message Mobile Terminated - CDR 

TAP Transferred Account Procedure 

T-CSI Terminating CAMEL Subscription Information 

TDP Trigger Detection Point 

TID Tunnel Identifier 

TLV Type, Length, Value (GTP header format) 

TMN Telecommunications Management Network 

TS Technical Specification 

TV Type, Value 

UMTS Universal Mobile Telecommunications System 

URA UTRAN Registration Area 

USIM User Service Identity Module 

USSD Unstructured Supplementary Service Data 

UTRAN UMTS Terrestrial Radio Access Network 

VAS Value Added Service 

VASP Value Added Service Provider 

VLR Visitor Location Register 

VMSC Visited MSC 

VPLMN Visited PLMN 



3.3 Symbols 



For the purposes of the present document the following symbols apply: 



A 

Bp 

Be 

Bi 

Bm 

Bs 

Ga 

Gb 
Gc 
Gd 
Gf 
Gi 
Gn 
Gp 



Gr 
Gs 

lu 

kbit/s 

Mbit/s 

Mc 



Interface between an MSC and a BSC 
Charging data collection interface between a CGF and a BS 
Charging data collection interface between the xMSC / HLR and a BS 
Charging data collection interface between a CCF and a BS 
Charging data collection interface between the MMS Relay Server and a BS 
Charging data collection interface between the SCF and a BS 

Charging data collection interface between a CDR transmitting unit (e.g. GGSN or SGSN) and a 
CDR receiving functionality (CGF) 
Interface between an SGSN and a BSC 
Interface between an GGSN and an HLR 

Interface between an SMS-GMSC and an SGSN, and between a SMS-IWMSC and an SGSN 
Interface between an SGSN and an EIR 

Reference point between the Packet-Switched domain and an external packet data network 
Interface between two GSNs within the same PLMN 

Interface between two GSNs in different PLMNs. The Gp interface allows support of Packet- 
Switched domain services across areas served by the co-operating Packet-Switched domain 
PLMNs 

Interface between an SGSN and an HLR 
Interface between an SGSN and an MSC/VLR 

Interface between the RNS and the core network. It is also considered as a reference point 
Kilobits per second 

Megabits per second. 1 Mbit/s = 1 million bits per second 
Interface between the MGW and (G)MSC server 
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R Reference point between a non-ISDN compatible TE and MT. Typically this reference point 

supports a standard serial interface. 
Reporting Area The service area for which an MS's location shall be reported 
Service Area The location accuracy level needed for service management purposes in the 3G-SGSN, e.g. a 

routing area or a cell. The 3G-SGSN can request the SRNC to report: i) the MS's current service 

area; ii) when the MS moves into a given service area; or iii) when the MS moves out of a given 

service area. 
Um Interface between the Mobile Station (MS) and the GSM fixed network part. The Um interface is 

the GSM network interface for providing Packet-Switched services over the radio to the MS. 

The MT part of the MS is used to access the Packet-Switched services in GSM through this 

interface. 
Uu Interface between the Mobile Station (MS) and the UMTS fixed network part. The Uu interface is 

the UMTS network interface for providing Packet-Switched services over the radio to the MS. 

The MT part of the MS is used to access the Packet-Switched services in UMTS through this 

interface. 



4 Architecture 

4.1 Charging IVIechanisms 

4.1.1 Generic Overview 

This subclause should explain something about Billing, Charging, AoC, Accounting, Charging Levels and Rating 

4.1.2 Offline Cinarging 

This subclause should explain charging based on CDR collection. 

4.1.3 Online Cinarging 

This subclause should explain charging based on charging event creation. 



£75/ 



3GPP TS 32.200 version 5.6.0 Release 5 



14 



ETSI TS 132 200 V5.6.0 (2004-03) 



4.2 Logical network and charging architecture 
4.2.1 3G CS, PS and Service architecture 

Figure 4.1 shows the 3G logical architecture for Release 4 as described in3GPP TS 23.002 [21]. 
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Figure 4.1 : Overview of thie 3G CS and PS Logical Architecture 

The 3"* Generation Mobile system is logically implemented on the GSM/GPRS structure through the addition of a new 
air interface supported by two network nodes, the RNC and the Node B. No inference should be drawn about the 
physical configuration on an interface from figure 4. 1 . 

The CAMEL entities are not shown in figure 4. 1 . For the relationship ship of the CAMEL entities to the core network 
entities illustrated above, refer to3GPP TS 23.002 [21]. 
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Figure 4.2: 3G charging logical architecture 

Figure 4.2 illustrates the 3'^'^ Generation charging logical architecture, which is subdivided by the two transmission 
planes, the Circuit Switched (CS) domain and the Packet Switched (PS) domain. The CDRs generated by the serving 
nodes (SGSN, GGSN) for the appropriate domain are forwarded via the Charging Gateway Function (CGF) entities to 
the Billing System for processing. Note that the SCF may also transfer CDRs directly to the Billing System. However, 
the current specifications do not include any CDR descriptions for the SCF. (While not shown explicitly in this figure, 
the VLR may also generate CDRs.)CDRs for the Multimedia Messaging Service (MMS) are delivered by the MMS 
Relay/Server when receiving or delivering multimedia messages to the MMS User Agent or to another Multimedia 
Messaging Service Environment (MMSE). CDRs from the MMS Relay/Server are transferred directly to the Billing 
System. The CGF has a significant role in the PS domain and is elaborated on in the subclause 4.3. 

The details of the connectivity from the CS/PS domain to the Service domain is out of scope for this document. For 
more information about possible implementations for MMS see 3GPP TS 23.140 [19]. 

4.2.2 IMS architecture 

Figure 4.3 describes the logical IMS architecture, as described in3GPP TS 23.002 [21]. 
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Figure 4.3: Overview of the IIVI Subsystem entities 

NOTE: This figure should be updated according to3GPP TS 23.002 after finalisation of IMS architecture by SA2. 

4.2.2.1 Architecture reference model for offline charging 

Figure 4.4 presents the offline IMS charging architecture for non-roaming scenario. 
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Figure 4.4: Offline IMS Charging architecture for non-roaming scenario 

NOTE: The topological merging of some of the Unes representing the Ga or Rf reference points for connecting 
with the CCF are performed for figure layout purposes only, and do not imply any other logical or 
physical association. 
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Figure 4.5 presents the offline IMS charging architecture for roaming scenario. 
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Figure 4.5: Offline IMS Charging architecture for roaming scenario 

NOTE 1 : The topological merging of some of the lines representing the Ga or Rf reference points for connecting 
with the CCF are performed for figure layout purposes only, and do not imply any other logical or 
physical association. 

NOTE 2: This diagram only depicts the case where the GGSN in the visited network is used (local access). 

4.2.2.2 Architecture reference model for online charging 

Figure 4.6 below presents the online IMS charging architecture. 



ETSI 



3GPP TS 32.200 version 5.6.0 Release 5 



18 



ETSI TS 132 200 V5.6.0 (2004-03) 



S-CSCF 



AS(s) 



MRFC 



SGSN 



Home(A) + Visited(A) 



ISC 



Ro 



Ro 



CAP 



Session 

Charging 

Function 



Rb 



Rating 
Function 



Correlation I 
Function 



I Account ] 



Bearer 

Charging 

Function 



Re 



Re 



Re 



Event 
Charging 
Function 

I SCCF I 



CPCF 



Online Charging System 



Charging 

^information 

How 



Home(B) + Visited(B) 



[ 



Bearer 

Charging 

Function 



Conelation 
Function 



Re 



Rb 



Re 



Re 



Event 
Charging 
Function 

I SCCF I 



CPCF 



Session 

Charging 

Function 



Rating 
Function 



Online Charging System 



ISC 



S-CSCF I 



Ro 



AS(s) 



Ro 



MRFC 



CAP 



SGSN 



Figure 4.6: Online IMS Charging architecture 

NOTE: The Charging Information Flow is FFS. 

Access Charging is performed using the CAP interface from the SGSN to the Bearer Charging Function. 

Session Charging is performed using the ISC interface between the IMS Session Charging Function and the S-CSCF. 
Routing to the Session Charging Function is performed as per regular ISC procedures. 

Event-based charging between an AS or MRFC and the Event Charging Function (ECF) is performed using the Ro 
reference point. The Ro reference point is described in subclause 7.3.1.1. ECF address information is distributed using 
SIP signalling such that Application Servers can use it to find the ECF. 

The Re reference point allows the interaction with a Rating server. 

The Re reference point allows to perform the following functions: 

• Interaction of the Event Charging Function with the Correlation Functions. Via the Correlation Function, the 
Bearer Charging Function and the Session Charging Function can be reached. 

• Correlation 

• Access to the Account of the subscriber. 

The Rb reference point allows to perform the following functions: 

• Interaction of the Session Charging Function with the Correlation Functions. Via the Correlation Function, the 
Bearer Charging Function and the Event Charging Function can be reached. 

• Correlation 

• Access to the Account of the subscriber. 

The SCCF and the CPCF, which are described in sub-clauses 4.3.3 and 4.3.4, constitute parts of the ECF. 
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4.3 Charging Functions 

4.3.1 Charging Gateway Function (CGF) 

The Charging Gateway Function (CGF), within the Packet-Switched domain, provides a mechanism to transfer 
charging information from the SGSN and GGSN nodes to the network operator's chosen Bilhng Systems. The Charging 
Gateway concept enables an operator to have just one logical interface between the CGF and the Billing System. The 
CGF may be supported in one of the following ways: 

as a centralised separate network element: the Charging Gateway(CG); 

as a distributed functionality resident in the SGSNs and GGSNs. 

Support of a centralised or distributed CGF in a network is implementation dependent and subject to 
vendor/manufacturer agreement. Regardless of the way in which the CGF is supported in the network, the functionality 
of the CGF is similar, figure 4.7 gives an overview of the two basic configurations: In scenario 1, the GSNs support an 
external interface to the charging gateways they are connected to. In scenario 2, the GSNs support the charging gateway 
functionality internally. 
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Figure 4.7: Basic architectural scenarios for the CGF location 

If the GSNs with an internal Charging Gateway Function also support the external interface, additional configurations 
as shown in figure 4.8 are possible. In scenario 3, the GSN with integrated Charging Gateway Function also acts as 
CGF for other GSNs. In scenario 4, the GSN with integrated Charging Gateway Function also supports the transmission 
of CDRs to external CGFs. 
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Configuration 3: Centralized Internal CGF 
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Figure 4.8: Optional scenarios for the CGF configuration 

The four scenarios in figures 4.7 and 4.8 are not exhaustive. 

The CGF provides the mechanism to transfer charging information from the SGSN and GGSN nodes to the network 
operator's chosen Billing Systems(s). The main functions of the CGF are: 

the collection of Packet-Switched CDRs from the Packet-Switched nodes generating CDRs; 

intermediate CDR storage buffering; 

the transfer of the CDR data to the billing systems. 

The CGF acts as storage buffer for near real-time CDR collection. It provides the CDR data to the billing system. The 
present document identifies the external interfaces of the CGF, but does not specify the internal functionality of the 
CGF. However, some of the CGF functionality is described to indicate its behaviour. The CGF may perform specific 
activities, such as consolidation of CDRs, pre-processing of CDR fields, filtering of un-required CDR fields, and adding 
of Operator defined fields for specific billing systems. These specific activities may be performed to optimise the 
charging information that is to be forwarded to the Billing System, which should reduce the load in the Billing System. 

The CGF can reside in a separate Network Element, the Charging Gateway(CG) or be integrated in the GSNs. The CGF 
can receive CDR from the GSNs in near real-time mode. It should have enough storage to enable it to transmit the 
collected charging data to the Billing System in file mode. The CGF may have to support several transmission protocols 
towards the Billing System, depending on the Billing System(s) used. One of the purposes of the CG is to reduce the 
number of different interfaces between the Billing System and the GGSNs and SGSNs sending charging data. If a new 
Billing System is introduced it shall be interfaced to the CGF, i.e. the protocol stacks and configurations of the GSNs do 
not need not to be updated. The usage and load of mass memory media can be more evenly distributed. The portion of 
the CGF embedded into a single physical device is called the Charging Gateway entity. The CGF may be distributed to 
several physical Charging Gateways or GSNs, to facilitate redundancy. If that Charging Gateway entity that is the 
Primary Charging Gateway entity, does not respond to communication originating from the GSNs, the GSNs will try to 
send the CDR data to a Secondary Charging Gateway entity. Here each GSN will have several IP addresses (of different 
priority) for the Charging Gateway entities, thus avoiding downtime of the CGF. 

4.3.2 Charging Collection Function (CCF) 

The Charging Collection Function's (CCF) main functionalities for IMS are in principle equivalent to the Charging 
Gateway Functions (CGF) that are used in the PS domain as described in subclause 4.3.1. Additional functions of the 
CCF are for further study. 

The CCF may be supported as a centralised separate Network Element or as an integrated functionality resident in the 
IMS Network Elements. In either case the Rf reference point is supported, but depending on the physical configuration 
it may be internal or external. 
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4.3.3 Session Charging Function (SCF) 

The Session Charging Function is responsible for Session Charging including the session control such as e.g. session 
termination. Other functions such as the Correlation Function communicate with the Session Charging Function via the 
Rb reference point. 

4.3.4 Bearer CInarging Function (BCF) 

The Bearer Charging Function performs the Bearer Charging. 



4.3.5 Event CInarging Function (ECF) 



The Event Charging Function (ECF) performs event-based charging (content charging). It makes use of the rating 
function in order to determine the value of the service rendered. The ECF may correlate several event-based charging 
requests. The ECF provides information via the Re reference point that triggers the Correlation Function to debit or 
credit the subscriber's account. Additional information sent by the ECF may also be used in the Correlation Function to 
correlate Event Charging with Bearer Charging and Session Charging. 

This specification addresses the following cases: 

the subscriber account, the ECF and the AS/MRFC (e.g. content server) are located in the same operator 
network. 

the AS/MRFC are in a different operator network than the ECF and the subscriber account. 

However, the scenario where each of the content charging functions (SCCF and CPCF) is located in different operator 
networks, and thus in different ECFs, is not addressed in Release 5. 

The SCCF and the CPCF, which are described below, constitute the ECF. 

4.3.5.1 Subscriber Content Charging Function (SCCF) 

The Subscriber Content Charging Function (SCCF) is always located in the same operator network as the account of 
the subscriber. The SCCF handles content charging requests that are made when the subscriber accesses the content. 
Upon such a content charging request, the SCCF may for example request the Correlation Function to check or to debit 
the subscriber's account. Content charging requests are received from the Content Provider Charging Function (CPCF). 

In particular, the SCCF has the following responsibilities: 

• to handle charging requests from the CPCF; 

• to obtain the identity of the subscriber's account; 

• to initiate a procedure to get a charging confirmation from the subscriber, if such a confirmation is needed; 

• to request to debit or to credit a certain amount from/to the subscriber's. 

4.3.5.2 Content Provider Charging Function (CPCF) 

The Content Provider Charging Function (CPCF) manages the account that is maintained for the content provider. 
Upon receipt of a charging request from the AS/MRFC, the CPCF processes the request and relays it to the SCCF. The 
CPCF modifies the account of the content provider accordingly. 

In particular, the CPCF has the following responsibilities: 

• to handle charging requests from the AS/MRFC. 

• to interact with the SCCF that manages the communication with the subscriber's account. This interaction may 
include requests to the SCCF to charge or to credit the account of the subscriber. 

As it is not expected that every content provider has a business relationship with every IMS network operator, the CPCF 
may be located in the operator network or in another network such as for example a Service Provider network that 
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supports the AS/MRFC. However, the second case (CPCF outside of the IMS network operator domain) is not specified 
in Release 5 of this specification. 

5 Circuit-Switched Domain 

5.1 Charging Principles 

5.1 .1 Requirements according to TS 22. 11 5 

The following high-level requirements summarize the more detailed requirements of3GPP TS 22.115 [2]. 

1. to provide a CDR for all charges incurred and requiring settlement between the different commercial roles; 

2. to allow itemised billing for all services (including CAMEL) charged to each subscription, including voice and 
data calls, and services offered by home environments, taking into account: 

information provided by the user (including authentication parameters, etc.); 

information provided by the serving network (including Serving Network Id, timestamps, etc.); 

information provided by the service (including charged party, long calling, multimedia, etc.). 

3. to allow fraud control by the Home Environment and the Serving network. 

5.1.2 Cinarging Information 

The MSC server and Gateway MSC server are responsible for the collection of all charging relevant information for 
each MS and PSTN connection and for the storage of this information in the form of CDRs. 

Circuit switched calls can be charged in one MSC server (the anchor MSC server) where all relevant data is available. 
That is guaranteed by routing all signalling information though the anchor MSC server even if the traffic channel of a 
call is routed through another MSC server due to handover. 

The Gateway MSC server acts as a gateway into other PLMN or fixed networks. Within the PLMN, the GMSC server 
is responsible for the generation of CDRs for calls routed from or into other networks. 

If subscribed CAMEL services apply to MS, the (G)MSC servers contain CAMEL subscription data providing the 
information required for invocation of the CAMEL dialogues for controlling the MS terminating and MS originating 
calls. Charging data record parameters resulting from the CAMEL treatment applying to MS calls is derived from the 
CAMEL subscription data. 

In addition to user subscribed services, specific dialled CAMEL services might be invoked which also influence 
existing records or even trigger the generation of separate records steered by service logic. 

In addition to the information collected from these network elements, network management functions are required for 
the administration of online charging data stored in the MSC servers. This data is employed to drive the charge display in 
the Mobile Station (MS) as required by the advice of charge (AoC) service and defined by TS 22.086 [8] and 
TS 22.024 [7]. 
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5.1.2.1 Subscriber billing 

The charging data collected from the HPLMN, interrogating PLMN, and/or VPLMN network elements is employed to 
determine the network utilisation charges for the basic and supplementary services utilised by the home subscribers of 
the PLMN. The charges calculated are then combined with the network access (subscription) charges and billed to those 
customers directly serviced by the PLMN. 

For those subscribers handled by Service Providers, the billing information is employed for both wholesale (Network 
Operator to Service Provider) and retail (Service Provider to Subscriber) billing. Consequently, having been processed 
by the PLMN Billing System, the charging data collected from the network elements may also be sent to the Service 
Provider for further processing. 

5.1 .2.2 Settlements of Charges 

5.1.2.2.1 Inter-PLMN accounting 

Inter-PLMN accounts for roaming traffic are determined in accordance with ITU-T principles (see ITU-T 
Recommendation D.93 [18]) and are settled by means of the GSM Association's Transferred Account Procedure (TAP). 

5.1 .2.2.2 'Visitors' from otiier PLMNs 

The CDRs collected from the network also include details of the services employed by visiting (roaming) subscribers. 
The charges for mobile originated calls (MOCs) and for supplementary services used are calculated as for home 
subscribers, converted to an agreed accounting currency and included in the CDRs for the TAP. Even if mobile 
terminated calls (MTCs) are zero-priced in the visited network (VPLMN), in the absence of 'optimised routing' the 
MTC TAP records are still required by the home network (HPLMN) in order to determine the re-routing charges from 
the HPLMN to the VPLMN. 

The TAP records generated are exchanged with each HPLMN on a regular basis. These TAP records form the basis of 
the invoice submitted by the VPLMN for the traffic carried. 

5.1 .2.2.3 'Home' subscribers roaming in other PLMNs 

The HPLMN receives TAP records from each VPLMN for services employed by home subscribers whilst roaming. 
These records are employed to verify the invoices from the VPLMN and to bill the home subscribers for the services 
used. The charges contained in the TAP records are converted from the accounting currency to the local currency and a 
handling surcharge (mark-up) is added if required. The TAP records are subsequently passed to the subscriber billing 
process described in subclause 5.1.2.1. 

5.1 .2.2.4 Fixed network operators and other service providers 

The settlement of accounts with the operators of fixed networks for traffic carried, is generally performed on a bulk 
basis according to the principles outlined in the ITU-T D-series recommendations. 

The traffic accounted for in this manner may include: 

outgoing (Mobile to Land) traffic; 

incoming (Land to Mobile) traffic; 

transit traffic, carried by intermediate networks; 

- signalhng (MAP/SCCP, CAP/SCCP) traffic such as location updates. 

Accounting information may also be required for the use of services provided by other operators such as short message 
service centres and other value added service (VAS) providers. 

The charges for the various traffic shares may be determined on the basis of the CDRs generated by the network 
elements or on the basis of bulk counters (accounting meter records) in the gateway MSC servers (GMSC servers). For 
the purpose of the present document, the management information required is assumed to be derived from CDRs. The 
management of accounting meters is outside the scope of the present document. 
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5.1.2.3 Service Information 

The charging data collected from the network elements may be used to provide statistical information concerning the 
use of services, by both home and visiting subscribers, within the network. In addition, the introduction of new services 
and/ or modifications to the tariffs of existing services may also require the distribution of the appropriate tariff 
information to the network elements for Advice of Charge purposes. 

5.1 .3 General Aspects of Charging Data 

Charging data record (CDR) generation and contents should be flexible and unnecessary redundancy in data should be 
avoided. Charging data are collected for successful and selected unsuccessful subscriber transactions. The subscriber 
transaction is seen as being successful in the MSC server (where the CDR is generated) either if a call is answered or if 
the Short Message Service Centre has confirmed the successful receipt of a mobile originated short message. 

Unsuccessful call attempts are recorded in the case of partial record generation due to CAMEL FollowOnCalls. If in 
such a call constellation the answer state is reached at least once, subsequent unsuccessful set-up of a connection 
configuration is also recorded in order to provide a complete sequence of FIRST, INTERMEDIATE and LAST records. 

Charging data is also collected for supplementary service activity. 

At termination of the subscriber transaction these data are formatted into CDRs. These records are forwarded onto MSC 
server's disk file which constitute the source for further transportation of that data to a Billing System. For the purpose 
of the present document, the CDRs are considered to be collected, in near real-time, by the following network elements: 
the MSC servers, MGWs, and location registers. 

The data collected by the network elements are sent to, or collected by, the appropriate Billing System for storage and 
further processing. 

Similarly, the tariff data required by the network elements to provide online charging information are distributed by the 
appropriate management system. 

5.2 Collection of Charging Data Records 
5.2.1 Charging Data Record Generation 

In order to provide the data required for the management activities outlined in the previous subclauses (billing, 
accounting, statistics etc.), the NEF of the MSC server and/or Location Registers shall be able to produce an charging 
data record for each of the following: 

Mobile originated call attempt; 

Mobile originated emergency call attempt; 

Mobile originated, call forwarding attempt; 

Mobile terminated call attempt; 

- Roaming call attempt in a gateway MSC server; 
Incoming call attempt in a gateway MSC server; 
Outgoing call attempt from a gateway MSC server; 
Transit call attempt; 

Terminating CAMEL call attempt; 
Supplementary service actions; 
HLR interrogation; 

- Location updating (HLR & VLR); 
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Short message service (point-to-point), mobile originated; 

Short message service (point-to-point), mobile terminated; 

Short message service (point-to-point), mobile originated interworking MSC server; 

Short message service (point-to-point), mobile terminated gateway MSC server; 

Common equipment usage; 

Mobile terminated location request; 

Mobile originated location request; 

Network induced location request. 

The purpose of each of these records are described in the following subclauses. A detailed formal description of the data 
defined in the present document is to be found in3GPP TS 32.205 [5]. 

5.2.1.1 AoC service 

In addition to the information collected from these Network Elements, network management functions are required for 
the administration of online charging data stored in the MSC server. Two levels of AoC service are available: 
information level and charging level. The information level is used only to provide AoC information to the user. For the 
charging level, if no approval of the AoC information by the MS is received in the MSC server, the call is released 
immediately. 

This data is employed to drive the charge display in the Mobile Station (MS) as required by the advice of charge (AoC) 
service and defined by 3GPP TS 22.086 [8] and 3GPP TS 22.024 [7]. Information used by the AoC service shall include 
a combination of the following: 

one or more basic services; and/or 

one or more supplementary services; and/or 

one or more network specific services; and/or 

one or more power capability classes (MS classmark); and/or 

the type of radio traffic channel used/ requested; 

the transparency mode of the basic service employed (transparent/non-transparent); 

the type of call or connection (e.g. MOC/ MTC). 
This list may also be extended to include additional network specific parameters. 
Parameters sent to the mobile station during the operation of the AoC service are recorded in the appropriate CDRs. 

5.2.1.2 CAMEL services 

A CAMEL service can be activated for originating, forwarded and terminated calls and originating SMS. Several fields 
describing CAMEL subscription and free format data are recorded to appropriate CDR. For originating and forwarded 
calls two different CAMEL services can be active and part of stored information is different depending on the CAMEL 
call model and which triggers occur. CAMEL fields describing usage level of service, CAMEL modified parameters 
and CAMEL initiated call forwarding include information for one call leg including impacts on all CAMEL services. 

5.2.1 .3 Use of supplementary services 

The recording of supplementary service usage permits the Billing System (BS) to specify the supplementary service 
actions (invocation, registration etc.). 

In addition to specifying the actions to be recorded, the BS may also determine how these events are to be recorded. 
Non-call related events, such as the administration of supplementary services by the subscriber via the MMI of the MS, 
shall result in the production of supplementary service action records. Call related events (e.g. invocation of 
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supplementary services) shall be recorded "in-line" in the appropriate CDR and/ or in a separate SS-action record 
depending on the configuration specified by the BS. 

Where the use of a supplementary service results in the production of further connections (e.g. call forwarding, multi- 
party service etc.) additional CDRs shall be produced to describe the relevant connections. The use of such services is 
described in more detail both in this subclause and in the example scenarios. 

5.2.1 .4 Use of call forwarding 

When one of the call forwarding services is used, the charging function of the MSC server that forwards the call, shall 
produce the MOC record for the forwarded part of the call. 

For further information concerning the recording of call forwarding services see the example scenarios in 
subclauses 5.2.2.6 and 5.2.2.7. 

5.2.1 .5 Use of call hold and multi-party services 

The use of the call hold service shall be recorded either in-line in the appropriate CDR or in a separate supplementary 
service "invocation" record as described above. The duration for which the call is held, i.e. is inactive, is not recorded. 

The use of the multi -party service requires a minimum of 3 subscribers and the use of a conference circuit. For the 
purpose of the following description the subscriber invoking the service is referred to as the conference originator ("A") 
and the conference call is regarded as consisting of a number of individual "legs" between the conference originator and 
the other parties ("B", "C", etc.) in the call. 

Normal MOC and MTC CDRs shall be generated for each party and each leg of the call. In addition, if common 
equipment records are enabled, a common equipment record shall be produced for the conference originator in order to 
record the use of a conference bridge and to record the total duration of the conference connection. 

EXAMPLE: Subscriber "C" calls subscriber "A". Subscriber "A" places the call from "C" on hold and makes a 

second call to subscriber "B". Subscriber "A" then invokes the multi-party service in order to 
set-up a conference call with "B" and "C". 

Assuming that the appropriate types of record are enabled, the following CDRs shall be produced: 

- An MOC record for subscriber "C" and the "C"->"A" leg of the call; 

- An MTC record for subscriber "A" and the "C"->" A" leg of the call; 

- An MOC record for subscriber "A" and the "A"->"B" leg of the call; 

An SS-Action record for the invocation of the call hold service by subscriber "A"; 

- An MTC record for subscriber "B" and the "A"->"B" leg of the call; 

An SS-Action record for the invocation of the multi-party service by subscriber "A"; 

A common equipment record for the use of the conference bridge by subscriber "A". 

Each of the MOC/MTC records for the conference originator ("A") shall include the supplementary service code for the 
multi-party service. 

Any subsequent action affecting only one leg of the connection shall be recorded either in a separate supplementary 
service action record or in-line in the appropriate CDR. Any action affecting the conference as a whole e.g. the 
originator holding the conference shall be recorded either in a separate supplementary service action record or in the 
common equipment usage record. 

For further information concerning the recording of multi-party services see the example scenario in subclause 5.2.2.9. 

5.2.1.6 Partial records 

In order to increase the security of the recording process and to simplify post-processing, it may be desirable to generate 
a sequence of CDRs to describe a single connection or transaction. 
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In case of connections of extended duration, the loss of a single CDR may result in an unacceptable loss of revenue. If 
the connection is, for example, recorded in a number of consecutive partial records generated at say hourly intervals, 
then the maximum loss of revenue is the equivalent of a one hour continuous connection. 

Most modern billing systems employ some form of cumulative credit-limit checking based on the stream of input 
CDRs. If however, a CDR is only produced at the end of the connection then a subscriber may avoid such credit 
checking by employing a connection for days, weeks or even months without a single CDR being produced. 

All of the records defined in TS 32.205 [5] are of variable length and some at least are potentially unlimited in size 
(SET OF, SEQUENCE OF etc.). However, the storage capacity of the internal records within the network element is 
normally subject to strict size limitations. Under such conditions a partial record may be required in order to circumvent 
internal resource limitations. For example, if an internal MOC record can only support the use of four supplementary 
service invocations then the use of a fifth may result in the generation of a partial record. 

Alternatively, for those manufacturers whose systems are based on fixed length records, partial records may be 
employed instead of the various lists contained within the present document definitions. In such cases a partial record 
will be produced each time one of the key fields alters during the connection. 

Finally, in case of radio link failure and subsequent call re-establishment partial records shall be generated to record the 
duration of the call prior to the radio link failure and the subsequent duration of the call once the call has been re- 
established. 

To summarise, the following events may result in the generation of a partial record: 

expiry of the partial record timer; 

change of basic service during a connection; 

change of location (LAC or Cell Id. or the Service Access Code, for UMTS) during a connection; 

change of MS classmark during a connection; 

change of AoC Parameters during a call; 

change of Radio Channel Type (full/half rate) during a call; 

radio link failure and subsequent call re -establishment; 

change of HSCSD Parameters (for GSM only) during a call; 

change of CAMEL destination (CAMEL controlled/initiated) during a call. 

All partial records for the same connection shall contain the same call reference and shall be ordered via a running 
sequence number. The time stamps involved shall apply to the individual partial records rather than the connection as a 
whole i.e. the "end" time stamp (duration) of one record shall, in general, coincide with the "start" time stamp (answer 
time) of the next. Each time a new partial record is created the cause for termination field of the previous record shall 
contain the value "partial record". The cause for termination of the final partial record shall contain the true cause for 
termination of the connection. 

It should be noted that the records produced in case of call re-establishment are not contiguous and that the value of the 
cause for term field in the record that is closed on radio link failure contains the value "partial record call re- 
establishment". 

The partial records generated may repeat each of the non-varying fields contained in the original record. Alternatively, a 
form of reduced partial record may be generated which includes only those fields required to identify the original record 
together with the field(s) that actually change. 

5.2.1 .7 Use of circuit-switched data services 

If data services are employed in conjunction with a Packet-Switched Public Data Network (PSPDN) then an 
MOC/MTC CDR may be produced in the originating/terminating MSC server and a gateway record in the 
gateway /interworking MSC server. If the packet volume is not available within the PLMN then this information may 
also be provided in the form of a CDR from the PSPDN. In such cases the Billing System is responsible for the 
correlation of the various records describing the connection. The definition of such PSPDN CDRs is outside the scope 
of the present document. 
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5.2.1 .8 Inter-MSC server handover 

In the case of an inter-MSC server handover the controlHng MSC server, as defined by TS 23.009 [22], remains in 
control of the connection and shall therefore, produce the CDR. For the avoidance of doubt, it is not necessary to 
produce CDRs in the subsequent MSC server(s). 

5.2.1.9 Call re-establishment 

In case of radio link failure as described in TS 24.008 [9], the MS may attempt to re-establish the call using the 
procedures described in TS 24.008 [9]. 

For the time period between the detection of the radio link failure by the mobile station and the successful 
re-establishment of the call, the advice of charge function in the MS is suspended as described in TS 24.086 [23]. In 
order to minimise the difference in charges between the online calculations performed by the MS and the offline 
processing on the basis of the CDRs, it is necessary to exclude the time taken for the re-establishment phase from the 
chargeable duration stored in the CDRs. 

If the re-establishment attempt fails then an ordinary CDR (MOC/MTC) shall be produced with the cause for 
termination value "stable call abnormal termination". The chargeable duration stored in this record covers the time 
period from "Answer" to the detection of the radio link failure by the MSC server. 

If, the attempt to re-establish the call succeeds then the current CDR shall be closed with the cause for termination value 
"partial record call re-establishment" and a new partial record shall be opened for the re-established call. The chargeable 
duration stored in the original record is once again the time period from "answer" to detection of the radio link failure 
by the MSC server. Both the "seizure" and "answer" times of the subsequent partial record correspond to the time at 
which the new traffic channel is allocated for the re-established call. 

Further radio link failures during the re-established call may result in the generation of additional partial records as 
described above. All of the partial records belonging to the same connection are identified by the same call reference 
and a running sequence number. 

NOTE: As the MS and MSC server may detect the radio link failure at different points in time, it is not possible 
to guarantee that the duration used for the AOC display corresponds to that recorded in the CDRs. The 
purpose of the above procedure is merely to minimise any discrepancies that may occur. 

5.2.1 .10 Restricted directory numbers 

In addition to the information pertaining to the served mobile subscriber (IMSI, MSISDN, etc.), the CDRs defined in 
the present document also contain the directory numbers of other parties involved in the recorded connections or 
transactions. In order to comply with data protection legislation, it is necessary to distinguish between those numbers 
that may be passed on to third parties and those that needs to be handled confidentially. As a result, each of the number 
fields (e.g. calling/connected number) contains the presentation and screening information defined in both 
TS 24.008 [9] and ISUP signalling. If this information is supported by the network, then even restricted numbers may 
be included in the appropriate records and suppressed offline by the administration or billing system. If this information 
is not supported then the entire directory number shall be suppressed by the MSC server/VLR. 

5.2.1.11 IMEI Observation 

In order to provide the data required by the mobile equipment management activities outlined in the previous 
subclauses, the MSC server shall be capable of producing IMEI tickets for each of the following events: 

usage of a blacklisted IMEI; 

usage of a greylisted IMEI; 

usage of an IMEI not found on the white list. 

An observed IMEI ticket is generated whenever greylisted, blacklisted or non-whitelisted mobile equipment is detected 
during an IMEI check. The purpose of the ticket is to link the mobile equipment under observation with its current user 
(IMSI). The ticket also includes information describing when and where the equipment was used to enable the tracking 
of such equipment. Finally, if the ticket was triggered by a call attempt, a call reference is provided in order to locate the 
corresponding CDR. 
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The IMEI tickets are generated by the MSC server performing the IMEI check. 

5.2.1 .12 Triggers for LCS-MT-CDR, LCS-MO-CDR and LCS-NI-CDR Charging 
Information Collection 

The LCS CDRs (LCS-MT-CDR, LCS-MO-CDR and LCS-NI-CDR) are used to collect charging information related to 
the LCS features that the PLMN provides in the Packet-Switched domain. 

These records include details such as Record Type, Served IMSI, Sequence Number etc. The LCS records are generated 
based on the following trigger conditions: 

• the LCS-MO-CDR, when the MSC receives the RANAP "Location report" message from the RNC; 

• the LCS-MT-CDR, when the MSC receives the RANAP "Location report" message from the RNC; 

• the LCS-NI-CDR, when the MSC receives the RANAP "Location report" message from the RNC. 



5.2.2 Charging scenarios 



This subclause contains a number of example scenarios illustrating the purpose and practical usage of the various types 
of records defined in the previous subclauses. These examples are by no means exhaustive. 

For the purpose of these examples, the following assumptions have been made: 

that the MSC server and VLR are co-located; 

that the records are sent to a post-processing system; 

that the generation of all of the record types described in this subclause has been enabled; 

that the HLR interrogation records are produced in the HLR and not the interrogating MSC server; 

that supplementary service actions are recorded in separate CDRs. 
The following conventions have been used for the figures contained within this subclause: 

1) Network connections and signalling transactions are illustrated by means of solid lines and referenced by number 

e.g. (1); 

2) Operation & Maintenance actions, such as the transfer of CDRs, are represented by means of dotted lines and 
referenced by letter e.g. (A); 

3) The Billing System has been included in some, but not all, of the examples. The only reason for this decision is 
to simplify the resulting figures. The presence of a Billing System is assumed even if not explicitly included. 

The following examples are included: 

1) Mobile to Land (outgoing) call; 

2) Land to Mobile (incoming) call; 

3) Mobile to Mobile call within the same network; 

4) Incoming call to a roaming subscriber; 

5) Incoming call to a PLMN Service Centre; 

6) Call Forwarding Unconditional; 

7) Call Forwarding conditional (on Busy); 

8) Delivery of a Mobile Terminated Short Message; 

9) Call Hold and Multi-party services; 

10) Outgoing call handled by CAMEL; 
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11) Incoming call handled by CAMEL without redirection; 

12) Incoming call to a roaming subscriber handled by CAMEL; 

13) Incoming call handled by CAMEL with redirection decided and forwarding leg handled by CAMEL; 

14) Incoming call handled by CAMEL without redirection and forwarded early using GSM SS but controlled by 
CAMEL; 

15) Incoming call handled by CAMEL without redirection and forwarded late using GSM SS but controlled by 
CAMEL; 

16) Early forwarded call controlled by CAMEL; 

17) Late forwarded call controlled by CAMEL; 

18) Incoming call handled by CAMEL with redirection imitated by CAMEL feature; 

19) Incoming call handled by CAMEL in MSC Server without redirection; 

20) Outgoing call handled by CAMEL Dialled CSI Trigger; 

21) Incoming call handled by CAMEL with redirection decided and forwarding leg handled by CAMEL; 

22) Mobile terminated location request. 

5.2.2.1 Mobile to land (outgoing) call 

Figure 5.1 illustrates a simple outgoing call from a PLMN subscriber "A" to a fixed network subscriber "B" (1). 

The originating MSC server (MSC-A) shall generate an MOC record for subscriber "A". 

The GMSC server shall create an outgoing gateway record for accounting with the fixed network including details of 
the point at which the call left the PLMN i.e. the GMSC server id. and outgoing trunk group. This record also includes 
time stamps to determine both the holding time of the outgoing trunk and the duration of the conversation. 

Even if the MSC server and GMSC server are co-located both records shall be produced. 

The records generated are subsequently transferred to the Billing System of the PLMN (A). 
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Figure 5.1 : Mobile to land (outgoing) call 



ETSI 



3GPP TS 32.200 version 5.6.0 Release 5 



32 



ETSI TS 132 200 V5.6.0 (2004-03) 



5.2.2.2 Land to mobile (incoming) call 

Figure 5.2 illustrates a simple incoming call from a fixed network subscriber "A" to a PLMN subscriber "B". 

The incoming call is first routed to a GMSC server (1). The GMSC server shall create an incoming gateway record for 
fixed network accounting purposes to record the point at which the call entered the network together with the time 
stamps required to calculate the holding time of the incoming trunk and the conversation duration. This gateway record 
shall contain the IMSI of the called subscriber. 

The GMSC server interrogates the HLR of the called subscriber in order to determine his current location (2). The HLR 
shall create an HLR interrogation CDR. 

The GMSC server routes the call to the MSC server at which the subscriber is currently registered (3). This terminating 
MSC server (MSC-B) shall create an MTC record for subscriber "B". 

Even if the MSC server and GMSC server are co-located both the MTC and gateway records shall be produced. 

The records generated are subsequently transferred to the Billing System of the PLMN (A). 
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Figure 5.2: Land to mobile (incoming) call 
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5.2.2.3 Mobile to mobile call within the same network 

Figure 5.3 illustrates a simple mobile to mobile call from subscriber "A" to subscriber "B" both within the same PLMN. 

The originating MSC server (MSC-A) shall produce an MOC record for the call to subscriber "B". 

Having received a set-up request from subscriber "A" (1), MSC-A interrogates the HLR of the called subscriber in order 
to determine his current location (2). The HLR shall create an HLR interrogation CDR. 

MSC-A routes the call to the MSC server at which subscriber is currently registered (3). This terminating MSC server 
(MSC-B) shall create an MTC record for subscriber "B". If MSC-A and MSC-B are co-located, then both the MOC and 
the MTC records shall be produced in the same MSC for this call. 

The records generated are subsequently transferred to the Billing System of the PLMN. 
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5.2.2.4 



Figure 5.3: Mobile to mobile call 



Incoming call to a roaming subscriber 



Figure 5.4 illustrates an incoming call from a fixed network subscriber "A" to a PLMN subscriber "B" who is currently 
roaming in another PLMN. 

The call is first routed to a GMSC server (1) and the GMSC server shall create an incoming gateway record for 
accounting purposes as described in subclause 5.2.2.2. The GMSC server interrogates the HLR of the called subscriber 
in order to determine his current location (2). The HLR shall create an Interrogation event record. 

The GMSC server routes the call to the VPLMN in which subscriber "B" is currently located (3). The GMSC server 
shall create an outgoing gateway record for accounting purposes. The GMSC server shall also create a roaming record. 
This record includes the IMSI of the "B" subscriber and may be used as a cross-check for the TAP information received 
from the VPLMN. 

The call is then routed by the VPLMN to the MSC server at which the subscriber is currently located (4). The GMSC 
server of the VPLMN shall produce an incoming gateway record and the terminating MSC server shall create an MTC 
record for the call to "B". 

The records generated are subsequently transferred to the Billing System of the appropriate PLMN (A). The MTC 
record generated by the terminating MSC server shall be employed to create the appropriate MTC TAP record. The 
TAP records shall be included in a TAP file and transmitted to the HPLMN (B). 
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Figure 5.4: Incoming call to a roaming subscriber 
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5.2.2.5 



Incoming call to a PLMN service centre 



Figure 5.5 illustrates an incoming call from a fixed network subscriber "A" to a Service Centre directly connected to an 
MSC server within a PLMN network. Examples for services provided by such a Service Centre include Voice Mail 
services, Operator services, etc. 

The call is routed to a GMSC server within the PLMN (1). The GMSC server analyses the dialled digits and routes the 
call directly to the MSC server to which the Service Centre is connected (2). 

As HLR interrogation is not required, there will be no HLR Interrogation record. The GMSC server shall however, 
create an incoming gateway record based on the point at which the call entered the network and the destination (Service 
Centre) of the call. 

The MSC server then connects the calling subscriber to the service centre. As no mobile subscriber is involved, the 
MSC server will not create an MTC record, however, the MSC server shall create a transit record describing the 
destination of the call. 

The records generated are subsequently transferred to the Billing System of the PLMN (A). 

It should be noted that without the transit record, the MSC server would not generate a record for this connection. 
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Figure 5.5: Incoming call to a PLMN service centre 
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5.2.2.6 



Call forwarding unconditional 



Figure 5.6 illustrates an incoming call from a fixed network subscriber "A" to a mobile subscriber "B" who has 
registered and activated Call Forwarding Unconditional (CFU) for the appropriate service. The call is subsequently 
forwarded to a second fixed network subscriber "C". 

For simplicity the registration and activation of CFU have not been included in the diagram. These actions shall of 
course be recorded in the appropriate supplementary service records. 

The incoming call is routed to a GMSC server (1). This part of the connection is identical to the scenario outUned in 
subclause 5.2.2.2. 

The GMSC server interrogates the HLR of the called subscriber in order to determine his current location (2). The HLR 
shall create an HLR interrogation CDR. The HLR informs the GMSC server that "B" has activated CFU to subscriber 
"C". 

The GMSC server forwards the call to the fixed network subscriber "C" (3). The GMSC server shall create an MTC 
record for the "B" subscriber for the call from "A" and an MOC (call forwarding) record for the "B" subscriber for the 
call to "C". Both records shall contain the supplementary service employed (CFU). The GMSC server shall also 
produce an outgoing gateway record as described in subclause 5.2.2.1. 

The records generated are subsequently transferred to the Billing System of the HPLMN (A). 
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Figure 5.6: Call forwarding unconditional 
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5.2.2.7 



Call forwarding conditional (on busy) 



Figure 5.7 illustrates a mobile originated call from subscriber "A" to a second mobile subscriber "B" who has registered 
and activated Call Forwarding on Busy (CFB) for the appropriate service. The call is subsequently forwarded to a third 
mobile subscriber "C". In this example, all three subscribers are currently located within the same (the home) network. 

For simplicity the registration and activation of CFB have not been included in the diagram. 

Having received a set-up request from subscriber "A" (1), the originating MSC server (MSC-A) interrogates the HLR of 
subscriber "B" in order to determine his current location (la). The call is then routed to MSC-B (2). 

MSC-A shall create an MOC record for subscriber "A" containing details of the call to "B". The HLR shall produce an 
HLR interrogation record. 

On determining that subscriber "B" is busy and that CFB is active, the forwarding MSC server/VLR (MSC-B) 
interrogates the HLR of subscriber "C" to determine his current location (2a) and forwards the call accordingly (3). 

MSC-B shall produce an MTC record for the "B" subscriber for the call from "A" and an MOC record for the "B" 
subscriber for the call to "C". Both records shall include the supplementary service employed (CFB). The HLR shall 
produce an Interrogation record. 

The terminating MSC server (MSC-C) shall create a normal MTC record for subscriber "C". 

The records generated are subsequently transferred to the Billing System of the PLMN. 
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Figure 5.7: Call forwarding conditional (busy) 
5.2.2.8 Delivery of a mobile terminated short message 

Figure 5.8 illustrates the delivery of a short message to a mobile subscriber. 

The short message service centre delivers the message to a GMSC server or gateway function (1). The GMSC server 
shall create an SMS gateway MT record. 

The GMSC server then interrogates the HLR of the subscriber to determine his current location (2). The HLR shall 
create an HLR interrogation record. 

The message is subsequently transmitted to the MSC server serving the mobile subscriber and finally to the mobile 
station of that subscriber (3). The MSC server shall create an SMS MT record. 
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The records generated are subsequently transferred to the post-processing system of the HPLMN (A). 
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Figure 5.8: Delivery of a short message to a mobile subscriber 

5.2.2.9 Call hold and multi-party service 

Figure 5.9 illustrates the use of the call hold and multi-party services. 

A mobile subscriber ("A") sets up an outgoing call (1) to an ISDN subscriber ("B"). This call is recorded as outlined in 
subclause 5.2.2.1. 

Subscriber "A" then invokes the call hold service. MSC-A shall produce a supplementary service action record for the 
invocation. 

Subscriber "A" then sets up a side-call (2) to a second mobile subscriber ("C") within the same network. This call is 
recorded as outlined in subclause 5.2.2.3. 

Subscriber "A" subsequently invokes the multi-party service in order to set up a three-party conference with "B" and 
"C". MSC-A shall produce a common equipment record for the use of a conference circuit by subscriber "A". This 
record shall record the duration of the whole conference irrespective of the number of parties subsequently added to, or 
removed from the conference connection. 

Note that the MOC records produced by MSC-A for both the A -> B and A -> C legs of the conference shall contain the 
supplementary service code for multi-party. 
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Figure 5.9: Call hold and multi-party service 



5.2.2.1 Outgoing call handled by CAMEL 

Figure 5.10 illustrates an outgoing CAMEL call from a mobile CAMEL subscriber "A" to a fixed network subscriber 
"B" (1). 

The "A" subscriber has an active 0-CSl (stored in the VLR). Therefore MSC server-A requests instructions from the 
gsmSSF which passes the CAMEL service key to the gsmSCF to indicate which service logic it should apply (2). 

The gsmSCF may interrogate the HLR for subscriber information. As a network option, the operator may refuse to 
provide the requested information. 

When gsmSCF processing is complete the call control is returned to MSC-A. 

MSC server-A generates an MOC record for the "A" subscriber. This record may be linked to an optional SCF-record. 
The record includes O-CSl data. 

The GMSC server routes the call to the "B" subscriber (3). The GMSC server shall create an outgoing gateway record 
as described in subclause 5.2.2.1. 

The generated records are subsequently transferred to the Billing System of the HPLMN (A). 
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The following records are generated in HPLMN in this call scenario. 

Table 5.1 : Records Generated for an Outgoing Call Handled by CAMEL 



GMSC server 


MSC server 


HLR 


Outgoing gateway record 


MOC record 


- 
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Figure 5.10: Outgoing call handled by CAMEL 

5.2.2.1 1 Incoming call handled by CAMEL without redirection 

Figure 5.11 illustrates an incoming call from a fixed network subscriber "A" to a mobile CAMEL subscriber "B". 

The incoming call is first routed to the GMSC server (1). The GMSC server shall create an incoming gateway record for 
fixed network accounting purposes. 

The GMSC server interrogates the HLR of the called subscriber in order to fetch the T-CSl (2). The HLR shall create an 
HLR interrogation record. 

The "B" subscriber has an active T-CSI. Therefore the GMSC server requests instructions from the gsmSSF which 
passes the CAMEL service key to a gsmSCF to indicate which service logic it should apply (3). 
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The gsmSCF may interrogate the HLR for subscriber information. As a network option, the operator may refuse to 
provide the requested information. 

When gsmSCF processing is complete the call control is returned to the GMSC server. The GMSC server shall generate 
a terminating CAMEL record which contains T-CSI data. 

The GMSC server interrogates the HLR in order to determine his current location (4). The HLR shall create an HLR 
interrogation record. 

The call is routed to MSC-B (5). An MTC record shall be generated. 

For avoidance of doubt, even if the MSC server and GMSC server are co-located both the MTC and gateway records 
shall be produced. 

The generated records are subsequently transferred to the Billing System of the HPLMN (A). 

The following records are generated in HPLMN in this call scenario. 

Table 5.2: Records Generated for an Incoming Call Handled by CAMEL without Re-direction 



GMSC server 


MSC server 


HLR 


Incoming gateway record 


IVITC record 


HLR interrogation record 


Terminating CAIVIEL record 
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Figure 5.11 : Incoming call handled by CAIUIEL without redirection 

5.2.2.12 Incoming call to a roaming subscriber handled by CAMEL 

Figures. 12 illustrates an incoming call from a fixed network subscriber "A" to a mobile CAMEL subscriber "B" who is 
currently roaming in another PLMN. 

The call is first routed to a GMSC server (1) and the GMSC server shall create an incoming gateway record for fixed 
network accounting purposes. 

The GMSC server interrogates the HLR of the called subscriber in order to fetch the T-CSl (2). The HLR shall create an 
HLR interrogation record. 

The "B" subscriber has an active T-CSl. Therefore the GMSC server requests instructions from the gsmSSF which 
passes the CAMEL service key to a gsmSCF to indicate which service logic it should apply (3). 

The gsmSCF may interrogate the HLR for subscriber information. As a network option, the operator may refuse to 
provide the requested information. 

When gsmSCF processing is complete the call control is returned to the GMSC server . The GMSC server shall 
generate a terminating CAMEL record which contains T-CSI data. 

The GMSC server interrogates the HLR in order to determine his current location (4). The HLR shall create an HLR 
interrogation record. 
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The GMSC server routes the call to the VPLMN in which subscriber "B" is currently located (5). The GMSC server 
shall create an outgoing gateway record for accounting purposes. The GMSC server shall also create a roaming record. 
This record includes the IMSI of the "B" subscriber and may be used as a cross-check for the TAP information received 
from the VPLMN. 

The call is then routed by the VPLMN to the MSC server at which the subscriber is currently located (6). The GMSC 
server of the VPLMN shall produce an incoming gateway record and the terminating MSC server shall create an MTC 
record for the call to "B". 

The records generated are subsequently transferred to the Billing System of the appropriate PLMN (A). The MTC 
record generated by the terminating MSC server shall be employed to create the appropriate MTC TAP record. The 
TAP records shall be included in a TAP file and transmitted to the HPLMN (B). 

The following records are generated in HPLMN in this call scenario. 

Table 5.3: Records Generated in the HPLMN for an 
Incoming Call to a Roaming Subscriber Handled by CAMEL 



GMSC server 


MSC server 


HLR 


Incoming gateway record 


- 


HLR interrogation record 


Terminating CAIVIEL record 






Roaming record 






Outgoing gateway record 







The following records are generated in VPLMN in this call scenario. 



Table 5.4: Records Generated in the VPLMN for an 
Incoming Call to a Roaming Subscriber Handled by CAMEL 



GMSC server 


MSC server 


HLR 


Incoming gateway record 


IVITC record 


- 
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Figure 5.12: Incoming call to a roaming subscriber handled by CAMEL 

5.2.2.13 Incoming call handled by CAMEL with redirection decided and forwarding leg 
handled by CAMEL 

Figure 5.13 illustrates an incoming call from a fixed network subscriber "A" to a mobile CAMEL subscriber "B". The 
call is subsequently forwarded to a second fixed network subscriber "C" by CAMEL initiated Call Forwarding. 

The incoming call is routed to the GMSC server (1). The GMSC server shall create an incoming gateway record for 
fixed network accounting purposes. 

The GMSC server interrogates the HLR of the called subscriber in order to fetch the T-CSl and O-CSl (2). 

The "B" subscriber has an active T-CSl. Therefore the GMSC server requests instructions from the gsmSSF which 
passes the CAMEL service key to a gsmSCF to indicate which service logic it should apply (3). 

The gsmSCF may interrogate the HLR for subscriber information. As a network option, the operator may refuse to 
provide the requested information. 

The gsmSCF modifies the Called Party number and sets the CAP parameter "Apply O-CSI'. When gsmSCF processing 
is complete the call control is returned to the GMSC server. The GMSC server shall generate a terminating CAMEL 
record which contains T-CSl data. 

The "B" subscriber has an active O-CSl. Therefore the GMSC server requests instructions from the gsmSSF which 
passes the CAMEL service key to a gsmSCF to indicate which service logic it should apply (4). 
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The gsmSCF may interrogate the HLR for subscriber information. As a network option, the operator may refuse to 
provide the requested information. 

When gsmSCF processing is complete the call control is returned to the GMSC server. 

The GMSC server redirects the call to the fixed network subscriber "C" (5). The GMSC server shall generate an MTC 
record for the "B" subscriber for the call from "A" and an MOC (call forwarding) record for the "B" subscriber for the 
call to "C". The MOC record includes O-CSI data and the parameter "CAMEL initiated CF indicator'. The GMSC 
server shall also produce an outgoing gateway record as described in subclause 5.2.2.1. 

The generated records are subsequently transferred to the Billing System of the HPLMN (A). 

The following records are generated in HPLMN in this call scenario. 

Table 5.5: Records Generated in the Incoming Call with 
Redirection Decided and Forwarded Leg Handled by CAMEL 



GMSC server 


MSC server 


HLR 


Incoming gateway record 


- 


HLR interrogation record 


Terminating CAIVIEL record 






IVITC record 






MOC (CF) record 






Outgoing gateway record 
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Figure 5.13: Incoming call handled by CAMEL with redirection decided 
and forwarding leg handled by CAMEL 

5.2.2.14 Incoming call handled by CAMEL without redirection and forwarded early 
using GSM SS but controlled by CAMEL 

Figure 5.14 illustrates an incoming call from a fixed network subscriber "A" to a mobile CAMEL subscriber "B". The 
call is subsequently forwarded to a second fixed network subscriber "C" by GSM SS Call Forwarding Unconditional 
(CFU) but controlled by CAMEL. 

For simplicity the activation and registration of CFU have not been included in the diagram. These actions shall of 
course be registered in the appropriate supplementary service records. 

The incoming call is routed to the GMSC server (1). The GMSC server shall create an incoming gateway record for 
fixed network accounting purposes. 

The GMSC server interrogates the HLR of the called subscriber in order to fetch the T-CSI and O-CSI (2). The HLR 
shall create an HLR interrogation record. The HLR informs the GMSC server that "B" has activated CFU. 

The "B" subscriber has an active T-CSl. Therefore the GMSC server requests instructions from the gsmSSF which 
passes the CAMEL service key to a gsmSCF to indicate which service logic it should apply (3). 

The gsmSCF may interrogate the HLR for subscriber information. As a network option, the operator may refuse to 
provide the requested information. 
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When gsmSCF processing is complete the call control is returned to the GMSC server. The GMSC server shall generate 
a terminating CAMEL interrogation record which contains T-CSI data. 

The "B" subscriber has an active O-CSI. Because the "B" subscriber has activated CPU he acts as the originating party 
for the forwarded leg. Therefore the GMSC server requests instructions from the gsmSSF which passes the CAMEL 
service key to a gsmSCF to indicate which service logic it should apply (5). 

The gsmSCF may interrogate the HLR for subscriber information. As a network option, the operator may refuse to 
provide the requested information. 

When gsmSCF processing is complete the call control is returned to the GMSC server. 

The GMSC server redirects the call to the fixed network subscriber "C" (6). The GMSC server shall generate an MTC 
record for the "B" subscriber for the call from "A" and an MOC (call forwarding) record for the "B" subscriber for the 
call to "C". The MOC record includes O-CSI data. The GMSC server shall also produce an outgoing gateway record as 
described in subclause 5.2.2. L 

If the B-subscriber do not have an active O-CSI the call is forwarded to the "C" subscriber after the first gsmSCF 
invocation. 

The generated records are subsequently transferred to the Billing System of the HPLMN (A). 

The following records are generated in HPLMN in this call scenario. 

Table 5.6: Records Generated in the Incoming call handled by CAMEL without redirection 
and forwarded early using GSM SS but controlled by CAMEL 



GMSC server 


MSC server 


HLR 


Incoming gateway record 


- 


HLR interrogation record 


Terminating CAIVIEL record 






IVITC record 






MOC (CF) record 






Outgoing gateway record 
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Figure 5.14: Incoming call handled by CAMEL without redirection 
and forwarded early using GSM SS but controlled by CAMEL 

5.2.2.15 Incoming call handled by CAMEL without redirection and forwarded late 
using GSM SS but controlled by CAMEL 

Figure 5.15 illustrates an incoming call from a fixed network subscriber "A" to a mobile CAMEL subscriber "B" who 
has registered and activated Call Forwarding on No Reply (CFNRY) for the appropriate service. The call is 
subsequently forwarded to a second fixed network subscriber "C". 

For simplicity the registration and activation of CFNRY have not been included in this diagram. These actions shall be 
recorded in the appropriate supplementary service records. 

The incoming call is routed to the GMSC server (1). The GMSC server shall create an incoming gateway record for 
fixed network accounting purposes. 

The GMSC server inteiTogates the HLR of the called subscriber in order to fetch the T-CSl and O-CSl (2). The HLR 
shall create an HLR interrogation record. 

The "B" subscriber has an active T-CSl. Therefore the GMSC server requests instructions from the gsmSSF which 
passes the CAMEL service key to the gsmSCF to indicate which service logic it should apply (3). 

The gsmSCF may interrogate the HLR for subscriber information. As a network option, the operator may refuse to 
provide the requested information. 
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When gsmSCF processing is complete the call control is returned to the GMSC server. The GMSC server shall generate 
a terminating CAMEL interrogation record which contains T-CSI data. 

The GMSC server interrogates the HLR in order to determine his current location (4). The HLR shall create an HLR 
interrogation record. 

The call is routed to MSC-B (5). The "B" subscriber do not answer the call. MSC-B shall produce an MTC record for 
the "B" subscriber for the call from "A". 

The "B" subscriber has an active O-CSI. Because the "B" subscriber has activated CFNRY he acts as the originating 
party for the forwarded leg. Therefore MSC-B requests instructions from the gsmSSF which passes the CAMEL service 
key to the gsmSCF to indicate which service logic it should apply (6). 

The gsmSCF may interrogate the HLR for subscriber information. As a network option, the operator may refuse to 
provide the requested information. 

When gsmSCF processing is complete the call control is returned to MSC-B. 

MSC-B forwards the call via the GMSC server to the "C" subscriber (7). MSC-B shall produce an MOC (call 
forwarding) for the "B" subscriber for the call to "C". The record includes O-CSI data. The GMSC server shall also 
produce an outgoing gateway record as described in subclause 5.2.2. L 

If the B-subscriber do not have an active O-CSI the call is forwarded to the "C" subscriber after detecting the call 
forwarding condition. 

The generated records are subsequently transferred to the Billing System of the HPLMN (A). 

The following records are generated in HPLMN in this call scenario. 

Table 5.7: Records Generated in the Incoming call handled by CAMEL without redirection 
and forwarded late using GSM SS but controlled by CAMEL 



GMSC server 


IMSC server 


HLR 


Incoming gateway record 


IVITC record 


- 


Terminating CAI\/IEL record 


MOC (CF) record 




Outgoing gateway record 
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Figure 5.15: Incoming call handled by CAMEL without redirection 
and forwarded late using GSM SS but controlled by CAMEL 

5.2.2.1 6 Early forwarded call controlled by CAMEL 

Figure 5.16 illustrates an incoming call from a fixed network subscriber "A" to a mobile CAMEL subscriber "B". The 
call is subsequently forwarded to a second fixed network subscriber "C" by GSM SS Call Forwarding Unconditional 
(CFU) but controlled by CAMEL. 

For simplicity the activation and registration of CFU have not been included in the diagram. These actions shall of 
course be registered in the appropriate supplementary service records. 

The incoming call is routed to the GMSC server (1). The GMSC server shall create an incoming gateway record for 
fixed network accounting purposes. 

The GMSC server interrogates the HLR of the called subscriber in order to fetch the O-CSI (2). The HLR shall create 
an HLR interrogation record. The HLR informs the GMSC server that "B" has activated CFU. 

The "B" subscriber has an active O-CSl. Because the "B" subscriber has activated CFU he acts as the originating party 
for the forwarded leg. Therefore the GMSC server requests instructions from the gsmSSF which passes the CAMEL 
service key to a gsmSCF to indicate which service logic it should apply (3). 

The gsmSCF may interrogate the HLR for subscriber information. As a network option, the operator may refuse to 
provide the requested information. 
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When gsmSCF processing is complete the call control is returned to the GMSC server. 

The GMSC server redirects the call to the fixed network subscriber "C" (5). The GMSC server shall generate an MTC 
record for the "B" subscriber for the call from "A" and an MOC (call forwarding) record for the "B" subscriber for the 
call to "C". The MOC record includes O-CSI data. The GMSC server shall also produce an outgoing gateway record as 
described in subclause 5.2.2.1. 

The generated records are subsequently transferred to the Billing System of the HPLMN (A). 

The following records are generated in HPLMN in this call scenario. 

Table 5.8: Records Generated in the Early forwarded call controlled by CAMEL 
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Figure 5.16: Early forwarded call controlled by CAMEL 



ETSl 



3GPP TS 32.200 version 5.6.0 Release 5 52 ETSI TS 1 32 200 V5.6.0 (2004-03) 

5.2.2.17 Late forwarded call controlled by CAMEL 

Figure 5.17 illustrates an incoming call from a fixed network subscriber "A" to a mobile CAMEL subscriber "B" who 
has registered and activated Call Forwarding on No Reply (CFNRY) for the appropriate service. The call is 
subsequently forwarded to a second fixed network subscriber "C". 

For simplicity the registration and activation of CFNRY have not been included in this diagram. These actions shall be 
recorded in the appropriate supplementary service records. 

The incoming call is routed to the GMSC server (1). The GMSC server shall create an incoming gateway record for 
fixed network accounting purposes. 

The GMSC server interrogates the HLR of the called subscriber in order to determine the current location (2). The HLR 
shall create an HLR interrogation record. 

The call is routed to MSC-B (3). The "B" subscriber do not answer the call. MSC-B shall produce an MTC record for 
the "B" subscriber for the call from "A". 

The "B" subscriber has an active O-CSl. Because the "B" subscriber has activated CFNRY he acts as the originating 
party for the forwarded leg. Therefore MSC-B requests instructions from the gsmSSF which passes the CAMEL service 
key to gsmSCF-B to indicate which service logic it should apply (4). 

The gsmSCF may interrogate the HLR for subscriber information. As a network option, the operator may refuse to 
provide the requested information. 

When gsmSCF processing is complete the call control is returned to MSC-B. 

MSC-B forwards the call via the GMSC server to the "C" subscriber (5). MSC-B shall produce an MOC (call 
forwarding) for the "B" subscriber for the call to "C". The record includes O-CSl data. The GMSC server shall also 
produce an outgoing gateway record as described in subclause 5.2.2.1. 

The generated records are subsequently transferred to the Billing System of the HPLMN (A). 

The following records are generated in HPLMN in this call scenario. 

Table 5.9: Records Generated in the Late forwarded call controlled by CAMEL 



GMSC server 


MSC server 


HLR 


Incoming gateway record 


IVITC record 


HLR interrogation record 


Outgoing gateway record 


MOC (CF) record 
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Figure 5.17: Late forwarded call controlled by CAMEL 

5.2.2.18 Incoming call handled by CAMEL with redirection initiated by CAMEL feature 

Figure 5.18 illustrates an incoming call from a fixed network subscriber "A" to a mobile CAMEL subscriber "B". The 
call is subsequently redirected to a second fixed network subscriber "C" by CAMEL initiated redirection. 

The incoming call is routed to the GMSC server (1). The GMSC server shall create an incoming gateway record for 
fixed network accounting purposes. 

The GMSC server interrogates the HLR of the called subscriber in order to fetch the T-CSI (2) and the O-CSl (2). The 
HLR shall create an HLR interrogation record. 

Since subscriber "B" has an active T-CSl and the trigger criteria are met the GMSC server requests instructions from 
the gsmSSF which passes the CAMEL service key to a gsmSCF to indicate which service logic it should apply (3). A 
terminating CAMEL interrogation record is generated in the GMSC server for invoking the terminating CAMEL call 
handling. 

The gsmSCF may interrogate the HLR for subscriber information. As a network option, the operator may refuse to 
provide the requested information. 

The gsmSCF returns a modified destination routing address to the GMSC server (without the option "apply O-CSI"). 
Therefore for the redirection leg (B-C) the CAMEL feature is not invoked. 
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The GMSC server redirects the call to the fixed network subscriber "C" (4). For fixed network accounting purposes the 
GMSC server shall generate an outgoing gateway record as described in subclause 5.2.2.1. 

The generated records are subsequently transferred to the Billing System of the HPLMN (A). 

The following records are generated in HPLMN in this call scenario. 

Table 5.10: Records Generated in the Incoming call handled by CAMEL 
with redirection initiated by CAMEL feature 



GMSC server 


MSC server 
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Incoming gateway record 
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Figure 5.18: Incoming call handled by CAMEL with redirection initiated and by CAMEL feature 

5.2.2.1 9 CAMEL Scenario for Visiting Terminator Trigger Calls 

Figure 5.19 illustrates an incoming call from a fixed network subscriber "A" to a mobile CAMEL subscriber "B". 
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The incoming call is first routed to the GMSC (1). The GMSC shall create an incoming gateway record for fixed 
network accounting purposes. 

The GMSC interrogates the HLR (2) of the called subscriber. The HLR shall create an HLR interrogation record. The 
call is routed to MSC-B(3). An MTC record shall be generated in MSC-B. 

The "B" subscriber has an active VT-CSI (stored in the VLR). For avoidance of doubt in this scenario, the "B" 
subscriber does not have an active T-CSI in the HLR. Therefore MSC-B requests instructions from the gsmSSF which 
passes the CAMEL service key to the gsmSCF to indicate which service logic it should apply (4). 

The gsmSCF may interrogate the HLR for subscriber information. As a network option, the operator may refuse to 
provide the requested information. 

When gsmSCF processing is complete the call control is returned to the MSC-B. The MSC-B shall generate a 
terminating CAMEL (TCR) record which contains VT-CSI data. 

The MSC-B routes the call to the "B" subscriber (5). 

For avoidance of doubt, even if the MSC and GMSC are co-located both the MTC/TCR and gateway records shall be 
produced. 

The generated records are subsequently transferred to the OS (A) either as event reports following the release of the 
connection or when collected by the OS. 

The following records are generated in HPLMN in this call scenario. 

Table 5.11 : Records Generated for Visiting Terminating Trigger Calls 



GMSC 


IMSC-B 


HLR 


Incoming gateway record 


MTC record 


HLR interrogation record 




Terminating CAIVIEL record 
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Figure 5.19: Incoming call handled by CAMEL in MSC Server without redirection 

5.2.2.20 Outgoing call handled by CAMEL with Dialled CSI Trigger 

Figure 5.20 illustrates an outgoing CAMEL call from a mobile CAMEL subscriber "A" to a fixed network subscriber 
"B" (1). 

The "A" subscriber has an active D-CSI (stored in the VLR and modified Called Party number matches D-CSI). 
Therefore MSC server-A requests instructions from the gsmSSF which passes the CAMEL service key to the gsmSCF 
to indicate which service logic it should apply (2). 

The gsmSCF may interrogate the HLR for subscriber information. As a network option, the operator may refuse to 
provide the requested information. 

When gsmSCF processing is complete the call control is returned to MSC-A. 

MSC server-A generates an MOC record for the "A" subscriber which contains D-CSI data. This record may be linked 
to an optional SCF-record. 

The GMSC server routes the call to the "B" subscriber (3). The GMSC server shall create an outgoing gateway record 
as described in TS 32.205 [5]. 

The generated records are subsequently transferred to the post-processing system (A) either as event reports following 
the release of the connection or when collected by the post-processing system. 
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The following records are generated in HPLMN in this call scenario. 

Table 5.12: Records Generated for an Outgoing Call Handled by CAMEL 



GMSC server 


MSC server 


HLR 


Outgoing gateway record 


MOC record 
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Figure 5.20: Outgoing call handled by CAMEL with Dialled CSI Trigger 

5.2.2.21 Incoming call handled by CAIVIEL with redirection decided and forwarding leg 

handled by CAIVIEL with Dialled CSI Trigger 

Figure 5.21 illustrates an incoming call from a fixed network subscriber "A" to a mobile CAMEL subscriber "B". The 
call is subsequently forwarded to a second fixed network subscriber "C" by CAMEL initiated Call Forwarding. 

The incoming call is routed to the GMSC server (1). The GMSC server shall create an incoming gateway record for 
fixed network accounting purposes. 

The GMSC server interrogates the HLR of the called subscriber in order to fetch the T-CSl, O-CSl and D-CSI (2). 

The "B" subscriber has an active T-CSl. Therefore the GMSC server requests instructions from the gsmSSF which 
passes the CAMEL service key to a gsmSCF to indicate which service logic it should apply (3). 
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The gsmSCF may interrogate the HLR for subscriber information. As a network option, the operator may refuse to 
provide the requested information. 

The gsmSCF modifies the Called Party number and sets the CAP parameter "Apply O-CSI'. When gsmSCF processing 
is complete the call control is returned to the GMSC server. The GMSC server shall generate a terminating CAMEL 
interrogation record which contains T-CSI data. 

The "B" subscriber has an active O-CSI. Therefore the GMSC server requests instructions from the gsmSSF which 
passes the CAMEL service key to a gsmSCF to indicate which service logic it should apply (4). 

The gsmSCF may interrogate the HLR for subscriber information. As a network option, the operator may refuse to 
provide the requested information. 

The gsmSCF modifies the Called Party number. When gsmSCF processing is complete the call control is returned to the 
GMSC server. 

The "B" subscriber has an active D-CSI (modified Called Party number matches D-CSI). Therefore the GMSC server 
requests instructions from the gsmSSF which passes the CAMEL service key to a gsmSCF to indicate which service 
logic it should apply (5). 

The gsmSCF may interrogate the HLR for subscriber information. As a network option, the operator may refuse to 
provide the requested information. When gsmSCF processing is complete the call control is returned to the GMSC 
server. 

The GMSC server redirects the call to the fixed network subscriber "C" (6). The GMSC server shall generate an MTC 
record for the "B" subscriber for the call from "A" and an MOC (call forwarding) record for the "B" subscriber for the 
call to "C". The MOC record includes O-CSI data, the parameter "CAMEL initiated CF indicator' and D-CSI data. The 
GMSC server shall also produce an outgoing gateway record as described in TS 32.205 [5]. 

The generated records are subsequently transferred to the post-processing system (A) either as event reports following 
the release of the connection or when collected by the post-processing system. 

The following records are generated in HPLMN in this call scenario. 

Table 5.13: Records Generated in the Incoming Call with 
Redirection Decided and Forwarded Leg Handled by CAMEL 



GMSC server 


MSC server 


HLR 


Incoming gateway record 


- 


HLR interrogation record 


Terminating CAIVIEL record 






IVITC record 






MOC (CF) record 






Outgoing gateway record 
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Figure 5.21 : Incoming call handled by CAMEL with redirection decided 
and forwarding leg handled by CAMEL with Dialled CSI Trigger 

5.2.2.22 Mobile terminated location request 

Figure 5.22 illustrates general network positioning for LCS clients external to the PLMN. 

An external LCS client requests the current location of a target UE from a GMLC (1). In this release the GMLC shall 
not create any LCS record. 

The GMLC server then interrogates the HLR of the target UE to be located to determine his current location (2). The 
HLR shall create an HLR interrogation record. 

The GMLC sends the location service request to the MSC indicated by the HLR. The MSC sends a Location Request 
message to RAN that initiates the positioning procedure (3). The MSC shall create an LCS-MT record. 

The records generated are subsequently transferred to the Billing System of the PLMN (A). 
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Figure 5.22: Mobile terminated location request 



Packet-Switched Domain 



6.1 Charging Principles 
6.1.1 Requirements 

The following are high-level requirements specific to the packet domain, derived from the requirements in 
3GPPTS 22.115 [2]. 

1) Every PDP context shall be assigned a unique identity number for billing purposes, (i.e. the charging id). 

2) Data volumes on both the uplink and downlink direction shall be counted separately. The data volumes shall 
reflect the data as delivered to and from the user. 

3) The charging mechanisms shall provide the duration of the PDP context with date and time information. 

4) The UMTS operator may define a subset of the charging information specified by Packet-Switched domain 
charging standards. This means that it shall be possible to configure the SGSN and GGSN for the CDR 
information generated. 

5) The GSNs shall be capable of handling the charging characteristics mechanism charging characteristics as 
specified in 3GPP TS 32.215 [6] provided through either HLR subscription data or default values. This is to 
improve charging record generation efficiency determined by the operator, based on the configuration of CDR 
trigger parameters at the GSNs. In particular the GSNs shall be able to: 

SGSN: receiving (MAP) and forwarding (Gn) of the charging characteristics data item according to the rules 
specified in 3GPP TS 32.215 [6]; 

SGSN/GGSN: extracting the charging characteristics profile index (from the charging characteristics data 
item), determining the appropriate profile data (e.g. CDR trigger rules) and applying the profile data 
according to the rules specified in 3GPP TS 32.215 [6]. 
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6) SGSN shall support charging of CAMEL services. 



6.1.2 Charging Information 



Charging information in the Packet-Switched domain network is collected for each MS by the SGSNs and GGSNs, 
which are serving that MS. The information that the operator uses to generate an invoice to the subscriber is operator- 
specific. Billing aspects, e.g. a regular fee for a fixed period, are outside the scope of the present document. 

The SGSN collects charging information for each MS related with the radio network usage, while the GGSN collects 
charging information for each MS related with the external data network usage. Both GSNs also collect charging 
information on usage of the Packet-Switched domain network resources. 

The GSNs shall collect the following charging information: 

1 . usage of the radio interface: the charging information shall describe the amount of data transmitted in MO and 
MT directions categorised with QoS and user protocols; 

2. usage duration: duration of PDP context is counted as the time interval from PDP Context activation to PDF 
Context Deactivation. 

3. usage of the general Packet-Switched domain resources: the charging information shall describe the usage of 
other Packet-Switched domain-related resources and the MSs Packet-Switched domain network activity (e.g. 
mobility management). 

4. destination and source: the charging information shall provide the actual source addresses used by the subscriber 
for the PDP context. The charging information shall describe the destination addresses with a level of accuracy 
as determined by the Access Point Name (APN). 

5. usage of the external data networks: the charging information shall describe the amount of data sent and received 
to and from the external data network. 

External networks can be identified by the Access Point Name (APN). 

6. location of MS: HPLMN, VPLMN, plus optional higher-accuracy location information. The highest accuracy 
location information available in a GGSN is a SGSN address. 

6.1 .3 General Aspects of Charging Data 

CDR generation and contents should be flexible and unnecessary redundancy in data should be avoided. 

1 . Each PDP context generates its own record types (the S-CDR for the SGSN and the G-CDR for the GGSN 
related to PDP contexts). 

2. The SGSN can optionally provide a record for mobility management of the attached MS in the M-CDR. 

3. The SGSN shall provide two SMS related records, in case of Packet-Switched domain delivered MO short 
message S-SMO-CDR and MT short message S-SMT-CDR. 

4. MS Location information shall be included in the SGSN PDP context records. 

5. Records shall only include relevant information, i.e. traffic activity since last record. 

6. Change of tariff period (if used) should not cause new CDRs to be sent to avoid peaks in data transfer. Instead 
such events should close the existing volume counters and open new ones when appropriate traffic is detected. 
This can be done by having a new record in the same message. It is up to the operator how often the CDRs are 
transferred from a GSN. 

7. Both SGSN and GGSN nodes shall collect information from same chargeable sessions (PDP contexts). A 
unique reference (Charging ID in combination with GGSN address) is needed to enable correlation between 
information from several records produced from same PDP context. 

8. The RNC shall collect the amount of not transferred downlink data, i.e., data that the RNC has either discarded 
or forwarded to a 2G-SGSN, for an MS's RABs when instructed by the 3G-SGSN. 
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9. The SGSN shall generate LCS related records MT-LR-CDR, MO-LR-CDR and NI-LR-CDR if the location 
request is routed through the SGSN. 

6.1 .4 Volume counting in RNC 

The 3G-SGSN counts all downlink data sent to the RNC over lu interface. Any discarded data between MS and RNC 
causes inaccurate charging, as the 3G-SGSN cannot account for this and subsequently causing overcharging. 
Additionally any buffered data in the RNC at RAB release or forwarded to another SGSN during handover is possible 
counted again i.e. twice, which causes overcharging. 

To avoid inaccurate charging at the 3G-SGSN, the 3G-SGSN will always instruct the RNC at RAB set-up to count the 
unsent downlink data towards the MS. 

The reporting of unsent data by the RNC to the 3G-SGSN will only occur at RAB release. This occurs at either the 
termination of the PDF context or handover. 

The 3G-SGSN shall not use the optional "Data Volume Request' message to RNC in any situation, as this shall cause a 
significant performance impact to both the RNC and 3G-SGSN. 

When 3G-SGSN receives a report of unsent data volume from the RNC at RAB release. The 3G-SGSN shall report this 
value to the "RNC Unsent Downhnk Volume' field in the S-CDR. 

6.1 .5 Generation of Cinarging ID 

The concept of serving connections is different in the Circuit-Switched domain to that for the Packet-Switched domain. 
Therefore different mechanisms are needed to supply the Billing Systems with charging information. 

In the Packet-Switched domain the complete PDP context handling can be switched over from an old SGSN to a new 
SGSN due to routing area updates with the consequence that charging records will be generated in more than one 
SGSN. Furthermore different data has to be collected in the SGSNs and GGSNs. So for one PDP context, charging 
records are needed from both the SGSN and GGSN. 

The Billing System (BS) shall be provided with all relevant information from the network to charge for that one 
activated PDP context. 

During the active PDP context all records, which belong to this context could normally be identified by the TID. 
However: 

an MS can activate and deactivate PDP contexts in a very short time interval, and these PDP contexts can have 
the same TID (only parallel established PDP contexts have different TIDs); 

different SGSNs can be involved in the same PDP context as described above; 

the timing clocks of the GSN elements may not be fully synchronised. 

The records of one PDP context may be correlated by the Billing System using a unique Charging ID number (C-ID) 
assigned to all records generated for that one PDP context. 

The unique C-ID is generated in the GGSN when the PDP context is activated. A C-ID is generated for each activated 
context, so that each has a unique C-ID. The C-ID shall be transferred from the GGSN to the new SGSN in the routing 
area update response message. All CDRs for each activated PDP context generated by each SGSNs and GGSNs shall 
therefore contain the same unique combination of the C-ID and GGSN address, to permit subsequent Charging 
Gateway/Billing System (BS) correlation of the generated CDRs. 

This combination of GGSN address together with the C-ID should be a unique identification over a long period of time 
in all Packet-Switched domain networks. 



6.1.6 Charging for SMS 



SMS transmission (MO or MT) can be provided in the Packet-Switched domain via the SGSN. The SGSN shall 
provide an S-SMO-CDR when short message is mobile originated and an S-SMT-CDR when it is mobile 
terminated. In addition, also SMS-IWMSC (MO-SMS) and SMS-GMSC (MT-SMS) may provide SMS related 
CDRs as described in subclause 5.2. 
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No active PDP context is required when sending or receiving short messages. If the subscriber has an active PDP 
context, volume counters of S-CDR are not updated due to short message delivery. 

The contents of S-SMO and S-SMT CDRs are presented in TS 32.205 [5]. 

6.1.7 Charging support for CAMEL 

CAMEL Packet-Switched domain interworking can be activated for the Packet-Switched session, SGSN PDP context 
and mobile originated SMS based on subscription information stored in HLR. Control point for all CAMEL interactions 
in Packet-Switched domain reside at gprsSSF typically co-located with SGSN. GGSN is not aware of CAMEL service 
at all. For more information about CAMEL interworking (see 3GPP TS 23.078 [13]). 

An M-CDR, S-CDR and S-SMO-CDR include basic information about CAMEL service information, such as service 
key and SCF address, and service usage, such as CAMEL modification information and amount of signalling. CAMEL 
service may also send transparent free format data in one or several messages to be stored in the CDR. Each received 
free format data indicates whether it is overwritten or appended to previously received free format data. 

CAMEL service may deny the GPRS attach, PDP context activation or sending of short message. CAMEL service may 
also change the APN determined by SGSN before activating PDP context or it may change the destination information 
of short message. 

CAMEL feature to download advice of charge parameters does not need to be supported because sending of these 
parameters down to MS and usage in the MS is not standardised for Packet-Switched domain terminals. The message 
itself shall however be supported and in case of a relative tariff switch is received, then at that tariff switch time volume 
counts shall be reported to CAMEL service. 



6.2 Charging Data Collection 



In order to provide the data required for the management activities outlined in the previous subclauses (billing, 
accounting, statistics etc.), the SGSN and GGSN shall be able to produce a CDRs for each of the following: 

- Charging Data in the SGSN (S-CDR); 

- Charging Data in the GGSN (G-CDR); 

- Mobile Station Mobihty Management Data in SGSN (M-CDR); 

- SMS Mobile Originated Data in SGSN (S-SMO-CDR); 

- SMS Mobile Terminated Data in SGSN (S-SMT-CDR); 

- Mobile Originated location request in SGSN (LCS-MO-CDR); 

- Mobile Terminated location request in SGSN (LCS-MT-CDR); 

Network Induced location request (LCS-NI-CDR). 

The contents and purpose of each of these records are described in the following subclauses. A detailed formal 
description of the data defined in the present document is to be found in TS 32.215 [6]. 

6.2.1 Charging Data Record Generation 

The S-CDR, M-CDR G-CDR, S-SMO-CDR, S-SMT-CDR, LCS-MO-CDR, LCS-MT-CDR and LCS-NI-CDR are 

generated by the SGSN and GGSN to collect charging information such that they may be subsequently transferred to 
the Charging Gateway Function (CGF). 

The generation of CDRs, partial CDRs and coherent trigger conditions (e.g. "maximum number of charging conditions 
changes") depend on the charging characteristics profile data which is determined via the charging characteristics 
profile index. The mechanism of conveying the charging characteristics data item (HLR -> SGSN -> GGSN) and 
determining the appropriate profile data by the GSNs is specified in 3GPP TS 32.215 [6].In the GSNs it shall be 
possible to activate and deactivate CDR generation for each Charging Characteristics profile. If CDR generation is 
activated, it shall be possible to define separate trigger conditions values per Charging Characteristics profile for the 
following triggers: 
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data volume limit; 

time (duration limit); 

maximum number of charging conditions changes (QoS change, Tariff Time change). 

The following subclauses describe the trigger conditions for collection of charging information and CDR generation by 
the SGSN/GGSN. 

6.2.1 .1 Triggers for S-CDR Charging Information Collection 

An S-CDR is used to collect charging information related to the PDP context data information for a mobile in the 
SGSN. 

If according to the Charging Characteristics profile data, CDR generation is activated an S-CDR shall be opened at PDP 
context activation. The record includes details such as Record Type, Served IMSI, Sequence Number etc. Not all of the 
charging information to be collected is static, and other charging information is directly depending on dynamic Packet- 
Switched service usage. 

The subsequent subclauses identify the conditions for adding information to, and closing the S-CDR for generation 
towards the CGF. 

6.2.1 .1 .1 Triggers for S-CDR Charging Information Addition 

The "List of Traffic Volumes" attribute of the S-CDR consists of a set of containers, which are added when specific 
trigger conditions are met, and identify the volume count separated for uplink and downlink traffic on encountering that 
trigger condition. Table 6.1 identifies which conditions are supported to trigger S-CDR charging information addition. 

Table 6.1 : Triggers for S-CDR charging information addition 



Trigger Conditions 


Description/Behaviour 


QoS Change 


A change in the QoS shall result in a "List of Traffic Data Volumes" container being added 
to the CDR. 


Tariff Time Change 


Qn reaching the Tariff Time Change a "List of Traffic Data Volumes " container shall be 
added to the CDR. 


CDR Closure 


A list of "List of Traffic Data Volumes" container shall be added to the S-CDR. 



6.2.1 .1 .2 Triggers for S-CDR Closure 

The S-CDR shall be closed on encountering some trigger conditions. Table 6.2 identifies which conditions are 
supported to permit closure of the S-CDR. 

Table 6.2: Triggers for S-CDR closure 



Closure Conditions | Description/Behaviour 



End of PDP Context 
within the SGSN 



Deactivation of the PDP context in the SGSN shall result in the CDR being closed. The trigger 
condition covers: 

- termination of PDP context, 

- SGSN change (inter-SGSN routing area update including intersystem change), 

- any abnormal release. 



Partial Record Reason 



O&IVI reasons permit the closure of the CDR for internal reasons. The trigger condition covers: 

- data volume limit, 

- time (duration) limit, 

maximum number of charging condition changes, 
management intervention, 

Intra-SGSN intersystem change (change of radio interface from GSIVI to UMTS or vice 
versa). 



The Partial Record generation trigger thresholds are those associated with the Charging Characteristics profile data. The 
Charging Characteristics profile data is determined as defined in 3GPP TS32.215 [6]. 
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The Partial Record generation trigger thresholds are GSN configuration parameters defined per charging characteristics 
profile by the operator through O&M means (refer to 3GPP TS32.215 [6]). 

In the event that the S-CDR is closed and the PDP context remains active, a further S-CDR shall be opened with an 
incremented Sequence Number in the SGSN. 

6.2.1 .2 Triggers for M-CDR Charging Information Collection 

An M-CDR is used to collect charging information related to the mobility management of a mobile in the SGSN. 

An M-CDR shall be opened for each mobile upon GPRS Attach, and record details such as Record Type, Served IMSI, 
Sequence Number etc. Not all of the charging information to be collected is static, and other charging information is 
directly dependent on the mobility of the MS as provided by the Radio Access Network (RAN). Subsequent partial 
records may be opened if the M-CDR is closed and the MS is still attached to the network. 

The subsequent subclauses identify the conditions for adding information to, and closing of the M-CDR for generation 
towards the CGF. 

NOTE: In case of a 3G or a combined 2G/3G SGSN, the specified mobility management handling implies that 
not every routing area update is captured by the core network, depending on the mobility management 
state of the UE. This may result in e.g. not every change of Routing Area being recorded in the M-CDR. 
For more information about mobility management procedures in GPRS, see TS 23.060 [25]. 

6.2.1 .2.1 Triggers for M-CDR Charging Information Addition 

The "Change of Location" attribute of the M-CDR consists of a set of containers, which are added when specific trigger 
conditions are met, and identify the time stamped routing area on encountering that trigger condition. Table 6.3 
identifies which conditions are supported to trigger M-CDR charging information addition. 

Table 6.3: Triggers for M-CDR Charging Information Addition 



Trigger Conditions 


Description/Behaviour 


Mobility Change 


A ctiange in the Routing Area shall result in a "Change of Location" container being added to 
the M-CDR. 



6.2.1 .2.2 Triggers for M-CDR Closure 

The M-CDR shall be closed on encountering some trigger conditions. Table 6.4 identifies which conditions are 
supported to permit closures of the M-CDR. 

Table 6.4: Triggers for M-CDR closure 



Closure Conditions 


Description/Behaviour 


End of MM Context within 
SGSN 


Deactivation of the MM context in the SGSN shall result in the CDR being closed. The 
trigger condition covers: 

- SGSN change (inter-SGSN routing area update including intersystem change), 

- GPRS detach, 

- any abnormal release. 


Partial Record Reason 


O&M reasons permit the closure of the CDR for internal reasons. The trigger condition 
covers: 

- time (duration) limit, 

maximum number of mobility changes, and 

- Management intervention, 

- Intra-SGSN intersystem change (change of radio interface from GSM to UMTS or vice 
versa). 



In the event that the M-CDR is closed and the mobile is still known to the SGSN, a further logical M-CDR shall be 
opened with an incremented Sequence Number in the SGSN. 
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6.2.1 .3 Triggers for G-CDR Charging Information Collection 

A G-CDR is used to collect charging information related to the packet data information for a mobile in the GGSN. 

If, according to the Charging Characteristics profile data, CDR generation is activated a G-CDR shall be opened at PDF 
context activation. The record includes details such as Record Type, Served IMSI, Sequence Number etc. Not all of the 
charging information to be collected is static, and other charging information is directly dependent on dynamic Packet- 
Switched service usage. 

The "List of Traffic Data Volumes" attribute of the G-CDR consists of a set of containers, which are added following 
specific trigger conditions, and identify the volume count on encountering that trigger condition. The trigger conditions 
are as for the S-CDR (see subclause 6.2.2.1 on "Triggers for S-CDR Charging Information Collection") with the 
following exceptions: 

an SGSN change will not close the G-CDR; 

an inter-PLMN SGSN change causes the closure of a partial record. 

Subsequent partial records may be opened if the G-CDR is closed and the PDP context is still active. 

The Partial Record generation trigger thresholds are those associated with to the determined Charging Characteristics 
profile data. The Charging Characteristics profile data is determined as defined in 3GPP TS32.215 [6]. 

The Partial Record generation trigger thresholds are GSN configuration parameters defined per charging characteristics 
profile by the operator through O&M means (refer to 3GPP TS32.215 [6]). 

In the event that the G-CDR is closed and the PDP context remains active, a further G-CDR is opened with an 
incremented Sequence Number in the GGSN. 

6.2.1 .4 Triggers for LCS-MT-CDR, LCS-MO-CDR and LCS-NI-CDR Charging 
Information Collection 

The LCS CDRs (LCS-MT-CDR, LCS-MO-CDR and LCS-NI-CDR) are used to collect charging information related to 
the LCS features that the PLMN provides in the Packet-Switched domain. 

These records include details such as Record Type, Served IMSI, Sequence Number etc. The LCS records are generated 
based on the following trigger conditions: 

• the LCS-MO-CDR, when the SGSN receives the RANAP "Location report" message from the RNC; 

• the LCS-MT-CDR, when the SGSN receives the RANAP "Location report" message from the RNC; 

• the LCS-NI-CDR, when the SGSN receives the RANAP "Location report" message from the RNC. 

6.2.2 Charging scenarios 

This subclause contains a number of example scenarios illustrating the purpose and practical usage of the various types 
of records defined in the previous subclauses. These examples are by no means exhaustive. 

For the purpose of these examples the following assumptions have been made: 

- the CDRs are sent to a CGF; 

the generation of all of the CDR types has been enabled. 

The following conventions have been used for the Figures 27, 28, 29 and 30, contained within this subclause: 

1) Network connections and signalling transactions are illustrated by means of solid lines and referenced by number 
e.g. (1). 

2) Operation & Maintenance actions, such as the transfer of CDRs, are represented by means of dotted lines and 
referenced by letter e.g. (A). 

NOTE: Visiting scenarios are excluded. 
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6.2.2.1 



Mobile to PDN Context 



Figure 6.1 illustrates a simple outgoing Packet-Switched context from a PLMN Packet-Switched service subscriber "A" 
to a mainframe "B" via a PDN (1). 

The respective PDP context is activated in the SGSN and GGSN and PDP PDUs are routed in MO and MT direction. 
The SGSN shall create an S-CDR and the GGSN shall create a G-CDR for subscriber "A". 

The records generated are subsequently transferred to the CGF (A). The CGF transfers the CDRs to the BS. 




Figure 6.1 : Mobile to PDN Context 

6.2.2.2 Mobile to Mobile Context 

Figure 6.2 illustrates a simple Packet-Switched mobile to mobile context within the same HPLMN. 

The respective A-party related PDP context is activated in the SGSN-A and the GGSN (1). 

After the location of subscriber "B" is determined, the B party related PDP context is activated (2) in the SGSN-B and 
the GGSN and PDP PDUs are routed in MO and MT direction. The SGSN-A shall create an S-CDR and the GGSN 
shall create a G-CDR for subscriber A, the SGSN-B shall create an S-CDR and the GGSN shall create a G-CDR for 
subscriber "B". 

If subscriber "A" and subscriber "B" use the same GGSN, both G-CDRs are produced at that GGSN. 

If session leg (2) requires a PDP context activation the respective PDP records will contain a network initiated PDP 
context activation-flag. 

The records generated are subsequently transferred to the CGF (A). The CGF transfers the CDRs to the BS. 
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Figure 6.2: Packet-Switched lUlobile to lUlobile Context 



6.2.2.3 



PDN to Mobile Context 



Figure 6.3 illustrates a simple incoming Packet-Switched domain context from a mainframe "A" to mobile subscriber 
"B" via a PDN (1). After the location of subscriber "B" is determined, the PDP context is activated (2). 

The GGSN receiving the PDUs shall generate a G-CDR whereas the SGSN currently serving subscriber "B" creates an 
S-CDR. These records contain a flag that the PDP context is activated due to network request. 

The records generated are subsequently transferred to the CGF (A). The CGF transfers the CDRs to the BS. 
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Figure 6.3: PDN to IVIobile Context 
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6.2.2.4 Mobile to PDN Context while roaming, GGSN in HPLMN 

Figure 6.4 illustrates an outgoing Packet-Switched context from a roaming mobile subscriber "A" to mainframe "B" via 
Boarder Gateway, inter PLMN backbone and GGSN of the HPLMN (1). 

The respective a-party related PDP context is activated in the SGSN and GGSN and PDUs are routed in MO and MT 
direction. The SGSN shall create an S-CDR (VPLMN) and a G-CDR is generated at the used GGSN (HPLMN) for 
subscriber "A". From the GGSN the packets are sent via the PDN to the mainframe "B". 

The records generated in the HPLMN and the VPLMN are subsequently transferred to the CGFs (A). The CGFs 
transfer the CDRs to the BS. (B) 

Later on the records created in the VPLMN are transferred from the BS to the BS of the HPLMN via TAP procedure 

(C). 

Note that this scenario is an example, representing only one case of roaming CDR generation. 
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Figure 6.4: Mobile to PDN Context whilst roaming via BG 



7 IM Subsystem 

7.1 Charging Principles 

7.1 .1 General Charging Requirements 

1 . The IMS charging architecture and mechanisms shall allow different charging models as required by regulatory 
conditions and inter-network policies. At least the following charging models shall be possible in a network: 

The calling party incurs charging entirely for both the IMS session level charging and the transport level 
charging (e.g. charging done at GPRS) at calling and called party sides. 
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The calling party incurs transport level charging on calling party's side only and the entire charges related to 
the IMS session level. In this charging model, a called party incurs the transport level charging associated 
with that session on called party's side. 

2. If the called party requests additional media components with regard to the initial request from calling party then 
called party can - depending on operational conditions of the service - be charged for these additional 
components. 

3. The A and B party's home networks shall be able to exchange information on the charging to be applied to the 
current session or to some media component of the session. The calling party's home network can then, 
according to the service and inter-operator agreement, apply appropriate charging. 

4. During session forwarding (e.g. A calls B and is "forwarded to C"), the initial calling party (A) incurs the 
charges from A to B while the forwarding party (B) incurs charges due to the "forwarded" session (e.g. from B 
toC). 

5. In case of roaming (A calls B that is roaming to IMS network C), the calling party (A) incurs charges up to the 
home network of B. The latter incurs additional charges due to roaming from home network B to network C. 

6. The IMS charging architecture shall allow the operator to support IMS Advice of Charge. 

7. The IMS charging architecture shall allow the operator to charge for the transport and/or for the session service 
and/or for the content. 

8. The IMS charging architecture shall allow the operator to charge per media component (e.g. voice, video). 

9. The IMS charging architecture shall allow the operator to provide a single pre-paid account for a subscriber. In 
this case, that account combines the charges incurred by services in CS, PS, IMS, and other domains. 

10. Charging indications received from the called network (such as free of charge) shall be taken into account by the 
Pre-paid mechanisms. 

1 1 . The IMS charging architecture shall provide means to correlate charging information generated at transport, 
service and content charging levels by the network entities in PS domain and IMS. 

NOTE: The called network can be - depending on regulatory and operational / trust conditions - the same IMS 
network as calling's party network or another IMS network or a non IMS network as e.g. Internet / PSTN 
/ ISDN / CS domain of a PLMN. 

7.1 .2 Correlation of Charging Information 
7.1.2.1 Charging Correlation Levels 

The following levels of correlation for IMS charging shall be considered: 

1. Correlation within a session. A session may comprise a number of media components. It shall be possible to 
correlate the charging data of the different media components belonging to a session. 

2. Correlation at media component level. For a session comprising several media components (such as audio and 
video), charging data is generated for each media component and needs to be correlated between network 
elements. For this, a component identifier shall be unique and shall clearly identify to which media flow of a 
session this charging information belongs to. This component identifier is not exchanged between network 
elements and is based on the ordering of media flows in the SDP. This ordering is the same as the one used in the 
binding information passed to the PS Domain. The multiple component identifiers within one PDP Context are 
not supported in this version of the document. 



Correlation between the IMS and the PS domain shall take into account the above described levels. 
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7.1 .2.2 Charging Correlation Principles 

To support the correlation of charging information, the following principles apply to both offline and online charging: 

1) The correlation of charging information for an IMS session is based on the use of IMS Charging Identifiers. 

2) The first IMS network entity within the SIP signalling path is responsible for assigning an ICID. This ICID shall 
then be passed along the whole SIP signalling path in an end-to-end manner. However, this shall not preclude 
further elements (CSCFs) along the session path generating additional identifiers to be passed along. When the 
AS is the initiator of the session, the AS is responsible for assigning the ICID. 

3) The ICID is passed to all IMS network entities in the SIP signalling path. This is performed using SIP signalling. 

4) For the charging correlation between the PS domain and the IMS, one or more GPRS Charging IDs, which 
identify the PDP contexts of the session [7], are passed from the PS domain to the IMS. More specifically, these 
identifiers need to be transferred from the GGSN to the P-CSCF. Also, the P-CSCF passes the ICID to the 
GGSN. The ICID is not passed to the SGSN 

5) The GPRS Charging IDs (GCIDs) and GGSN Address are passed by the P-CSCF to the S-CSCF and the AS 
using SIP signalling. Along with the ICID, the S-CSCF passes the GCIDs and GGSN address to onHne and 
offline charging functions. The GCIDs and GGSN address are not transferred from one Home IMS (e.g. of the 
A-Party) to another Home IMS (e.g. the one of the B-Party). 

6) The ICID applies for the duration of the event with which it is associated. For example, an ICID assigned for 
session establishment is valid until session termination, etc. 

7) The charging correlation identifiers (ICIDs, GCIDs) shall not be passed to the UE. They may however be passed 
to An Application server connected as an endpoint. 

The detailed effects of certain complex scenarios (e.g. forking, multiparty sessions) to these charging correlation 
principles are for further study. 



7.1 .3 Exchange of charging information between networks 

7.1 .3.1 Charging information flow between home IMS networks 

The Charging information flow may support the following functionalities: 

Indication of who wants to subsidize whom (e.g. "A-party pays" or "reverse charge call"); 

Indication of media resources to be subsidized (e.g. final SDP negotiated between A and B UEs). 
The following mechanisms have been identified for charging information flow: 

Pre-arranged mechanism based on secure relation between networks; 

Additionally, real-time negotiations on a per-session basis may be conducted. 

7.1 .3.2 Identification of Operators for Charging 

To enable the different operators involved in IMS sessions to identify each other, the Inter Operator Identification 
concept (lOI) is introduced. lOI allows operators involved with session signalling to identify each other by exchanging 
operator identification information within the SIP signalling. The lOI is composed of one pair of originating lOI and 
terminating lOI. The (lOI concept may help to support inter operator charging. 

The following requirements relate to the lOI concept: 

The lOI concept shall allow operators to uniquely identify each other for the SIP based requests; for example 
between A's HPLMN and B's HPLMN. 

The lOI concept can be used for inter operator accounting identification purposes. 
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It shall be possible to prevent the information used for lOI from being passed to the UE. 

It shall be possible to apply the lOI concept on a peer to peer basis between operators. It shall be possible to use 
different identity values for operator identification between operators involved in IMS sessions. 

lOI identities shall be included within SIP signalling: 

When a SIP request is passed out of a network the lOI identity of that network shall be included in the SIP 
signalling. 

When a SIP response is returned the lOI identity of that responding network shall be included in the SIP 
signalling. 

Each network is responsible for including its own unique lOI Identity into the SIP signalling. The lOI Identity 
shall be unique for each operator (for example the lOI Identity of Home Operator A is different from Home 
Operator B). 

lOI Identities received in the session signalling shall be incorporated into the CDRs produced by the IMS 
network elements. The operator identification information may be used for inter operator accounting purposes. 

The allocation of the lOI values for the operators is outside the scope of 3GPP standardization. 



NOTE: The relationship of the lOI concept with security aspects between operators is for further study. 

7.2 Offline Charging Data collection 

7.2.1 Charging Data Record (CDR) creation 

7.2.1 .1 Offline charging reference point IMS Network Entity - CCF (Rf) 

Offline charging between the CCF and each of the IMS network entities, i.e. I-CSCF, P-CSCF, S-CSCF, MGCF, 
MRFC, BGCF and AS is performed using the Rf reference point. Rf is an interface that is specified in TS 32.225 [24]. 

The Rf reference point shall allow for at least the following features: 

Reliable transfer of Charging Information with acknowledgement mechanisms from the Network Element to the 
CCF. 

Support redundancy mechanisms. 



7.3 Online event-based Charging 



Event-based charging between an AS or MRFC and the ECF is performed using the Ro reference point. Ro is an 
interface that is standardised in TS 32.225 [24]. The Ro reference point supports integrity protection and authentication 
for the case that the AS/MRFC is outside the operator domain. 

7.3.1 Basic Principles 

There are two sub-functions for online charging that require a more detailed description: rating and unit determination. 
Both rating and unit determination can be implemented centralized, i.e. on the ECF, or decentralized, that is, on the 
AS/MRFC. 

Unit determination refers to the calculation of the number of non-monetary units (service units, data volume, time and 
events) that shall be assigned prior to starting service delivery. 

• With Centralized Unit Determination, the ECF determines the number of non-monetary units that a certain 
service user can consume based on a service identifier received from the AS/MRFC. 
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• With the Decentralized Unit Determination approach, the AS/MRFC determines itself how many units are 
required to start service delivery, and requests these units from the ECF. 

After checking the service user's account balance, the ECF returns the number of granted units to the AS/MRFC. The 
AS/MRFC is then responsible for the supervision of service delivery. Particularly, the AS/MRFC shall limit service 
delivery to the corresponding number of granted units. 

Rating refers to the calculation of a price out of the non-monetary units calculated by the unit determination function. 

• With the Centralized Rating approach, the AS/MRFC and the ECF exchange information about non-monetary 
units. The ECF translates these units into monetary units. The centralized rating approach is well suited in 
deployments where the AS/MRFC is within the network operator domain. 

• With the Decentralized Rating approach, the corresponding rating control is performed within the AS/MRFC. 
Consequently, AS/MRFC and ECF exchange information about monetary units. This approach may be favourable 
for external AS/MRFC deployment. 

Two cases for online event charging can be distinguished: immediate event charging and event charging with unit 
reservation. In the case of immediate event charging, granting units to the AS/MRFC is performed in a single operation 
that also includes the deduction of the corresponding monetary units from the subscriber's account. In contrast, event 
charging with unit reservation includes also the process of requesting, reserving and possibly returning units. The 
deduction of the corresponding monetary units then occurs upon conclusion of the event charging transaction. 

7.3.2 Basic Operations and Scenarios 

Immediate event charging is performed by the use of the "Debit Units" operation: 

• "Debit Units Request"; sent from AS/MRFC ^ ECF 

After receiving a service request from the subscriber, the AS/MRFC sends a Debit Units Request to the ECF. The 
AS/MRFC may either specify a service identifier (centralised unit determination) or the number of units requested 
(decentralised unit determination). 

• "Debit Units Response"; sent from ECF ^ AS/MRFC 

The ECF replies with a Debit Units Response, which informs the AS/MRFC of the number of units granted as a 
result of the Debit Units Request. This includes the case where the number of units granted indicates the permission 
to render the requested service. 

In addition, the "Reserve Units" operation is used in case of event charging with reservation: 

• "Reserve Units Request"; sent from AS/MRFC ^ ECF 

Request to reserve a number of units for the service to be provided by an AS/MRFC. In case of centralised unit 
determination, the AS/MRFC specifies a service identifier in the Reserve Unit Request, and the ECF determines the 
number of units requested. In case of decentralised unit determination, the number of units requested is specified by 
the AS/MRFC. 

• "Reserve Units Response"; sent from ECF ^ AS/MRFC 

Response from the ECF which informs the AS/MRFC of the number of units that were reserved as a result of the 
"Reserve Units Request". 

The consumed units are deducted from the subscriber's account after service delivery. Thus, the reserved and 
consumed units are not necessarily the same. Using this operation, it is also possible for the AS/MRFC to modify 
the current reservation, including the return of previously reserved units. 

7.3.3 Cinarging Scenarios 

In order to perform event charging via Ro, the scenarios between the involved entities UE-A, ECF and AS/MRFC need 
to be defined. The charging flows shown in this subclause include scenarios with immediate event charging and event 
charging with reservation. In particular, the following cases are shown: 

1) Immediate Event Charging 

a) Decentralized Unit Determination and Centralized Rating 

b) Centralized Unit Determination and Centralized Rating 
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c) Decentralized Unit Determination and Decentralized Rating 

2) Event charging with Reservation 

a) Decentralized Unit Determination and Centralized Rating 

b) Centralized Unit Determination and Centralized Rating 

c) Decentralized Unit Determination and Decentralized Rating 

The combination of Centralized Unit Determination with Decentralized Rating is not possible. 

7.3.3.1 Immediate Event Charging 

7.3.3.1 .1 Decentralized Unit Determination and Centralized Rating 

In the following scenario, AS/MRFC asks the ECF to assign a defined number of units. 
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5. Account 
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8. Credit Unit Control (com.) 
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Figure 7.1 : Immediate Event Charging with Centralized Rating and Decentralized Unit Determination 



1 . SIP Session Establishment: the SIP session is established and the UE-A requests the desired content from the 
AS/MRFC. 
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2. Units Determination: depending on the requested service the AS/MRFC determines the number of units 
accordingly. 

3. Debit Units Request: the AS/MRFC requests the ECF to assign the defined number of units. 

4. Rating Control: assisted by the rating entity the ECF calculates the number of monetary units that represents the 
price for the number of units determined in item 2. 

5. Account Control: provided that the user's credit balance is sufficient, the ECF triggers the deduction of the 
calculated amount from the subscriber's account. 

6. Debit Units Response: the ECF informs the AS/MRFC of the number of granted units. 

7. Content/Service Delivery: the AS/MRFC delivers the content/service at once, in fractions or in individually 
chargeable items, corresponding to the number of granted units. 

8. Credit Unit Control (cont.): this function block is optional and a replication of items 2 to 6. 

9. Content/Service Delivery (cont.): the continuation of content delivery occurs in correspondence with the 
occurrence of item 8. 

10. SIP Session released: the SIP session is released. 



7.3.3.1.2 



Centralized Unit Determination and Centralized Rating 



In the following scenario, AS/MRFC asks the ECF to assign units based on the service identifier specified by the 
AS/MRFC. 
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Figure 7.2: Immediate Event Charging with Centralized Rating and Centralized Unit Determination 
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1 . SIP Session Establishment: the SIP session is established and the UE-A requests the desired content from the 
AS/MRFC. 

2. Debit Units Request: depending on the service requested by the UE-A, the AS/MRFC selects the service identifier 
and forwards the Debit Units Request to the ECF. 

3. Units Determination: the ECF determines the number of non-monetary units needed for the content/service 
delivery, based on the received service key. 

4. Rating Control: assisted by the rating entity the ECF calculates the number of monetary units that represent the 
price for the number of units determined in item 3. 

5. Account Control: provided that the user's credit balance is sufficient, the ECF triggers the deduction of the 
calculated amount from the subscriber's account. 

6. Debit Units Response: the ECF informs the AS/MRFC of the number of granted units. This includes the case 
where the number of units granted indicates the permission to render the service that was identified by the received 
service key. 

7. Content/Service Delivery: the AS/MRFC delivers the content/service at once, in fractions or in individually 
chargeable items, corresponding to the number of granted units. 

8. Credit Service Control (cont.): this function block is optional and a replication of items 2 to 6. 

9. Content/Service Delivery (cont.): the continuation of content delivery occurs in correspondence with the 
occurrence of item 8. 

10. SIP Session released: the SIP session is released. 



7.3.3.1.3 Decentralized Unit Determination and Decentralized Rating 

In the following scenario, the AS/MRFC asks the ECF to assure the deduction of an amount of the specified number of 
monetary units from the subscriber's account. 
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Figure 7.3: Immediate Event Charging with Decentralized Rating and Decentralized Unit 

Determination 



1 . SIP Session Establishment: the SIP session is established and the UE-A requests the desired content from the 
AS/MRFC. 

2. Units Determination: depending on the service requested by the UE-A, the AS/MRFC determines the number of 
units accordingly. 

3. Rating Control: the AS/MRFC calculates the number of monetary units that represent the price for the number of 
units determined in item 2. 

4. Debit Units Request: the AS/MRFC requests the ECF to assure the deduction of an amount corresponding to the 
calculated number of monetary units from the subscriber's account. 

5. Account Control: provided that the user's credit balance is sufficient, the ECF triggers the deduction of the 
calculated amount from the subscriber's account. 

6. Debit Units Response: the ECF indicates to the AS/MRFC the number of deducted monetary units. 

7. Content/Service Delivery: the AS/MRFC delivers the content/service at once, in fractions or in individually 
chargeable items, corresponding to the number of units as specified in items 2 and 3. 

8. Credit Amount Control (cont.): this function block is optional and a replication of items 2 to 6. 

9. Content/Service Delivery (cont.): the continuation of content delivery occurs in correspondence with the 
occurrence of item 8. 

10. SIP Session released: the SIP session is released. 
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7.3.3.1.4 



Further Options 



In addition to the flows that are specified in the previous subclauses, the Debit Unit operation may alternatively be 
carried out concurrently with service delivery, or after completion of service delivery. 



7.3.3.2 



Event charging with Reservation 



7.3.3.2.1 



Decentralized Unit Determination and Centralized Rating 



In the following scenario, the AS/MRFC requests the reservation of units prior to service delivery. An account debit 
operation is carried out following the conclusion of service delivery. 
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Figure 7.4: Event Charging with Reservation / Decentralized Unit Determination and Centralized 

Rating 
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1 . SIP Session Establishment: the SIP session is established and the UE-A requests the desired content/service from 
the AS/MRF. 

2. Units Determination: depending on the requested service the AS/MRFC determines the number of units 
accordingly. 

3. Reserve Units Request: the AS/MRFC requests the ECF to reserve the number of units determined in item 2. 

4. Rating Control: assisted by the rating entity the ECF calculates the number of monetary units that represents the 
price for the number of units determined in item 2. 

5. Account Control: the ECF checks whether the user's account balance is sufficient for the requested reservation. 

6. Reservation Control: if the user's account balance is sufficient then the corresponding reservation is made. 

7. Reserve Units Response: the ECF informs the AS/MRFC of the reserved number of units. Items 3 to 7 may be 
repeated several times. 

8. Reserved Units Supervision: simultaneously with the service delivery, the AS/MRFC monitors the consumption 
of the reserved units. 

9. Content/Service Delivery: the AS/MRFC delivers the content/service at once, in fractions or in individually 
chargeable items, corresponding to the reserved number of units. 

10. Debit Units Request: the AS/MRFC requests the ECF to assure the deduction of an amount corresponding to the 
consumed number of units from the subscriber's account. In the case that no further units are required for this 
service, an appropriate indication triggering the release of the remaining reservation is given. 

1 1 . Rating Control: assisted by the rating entity the ECF calculates the number of monetary units to deduct from the 
subscriber's account. 

12. Account Control: the ECF triggers the deduction of the calculated amount from the subscriber's account. 

13. Debit Units Response: the ECF informs the AS/MRFC of the actually deducted units. Items 10 to 13 may be 
repeated several times. 

14. SIP Session Release: the SIP session is released. 



7.3.3.2.2 Centralized Unit Determination and Centralized Rating 

In the following scenario, the AS/MRFC requests the ECF to reserve units based on the service identifier specified by 
the AS/MRFC. An account debit operation is carried out following the conclusion of service delivery. 



£75/ 



3GPP TS 32.200 version 5.6.0 Release 5 



80 



ETSI TS 132 200 V5.6.0 (2004-03) 



ECF 
(SCCF, CPCF) 



1. SIP Sesfion established 



2. Reserve Units Request (Service Key) 



3. Units 
Determination 



I 



4. Rating Control 



5. Account 
Control 



6. Reservation 
Control 



7. Reserve Units Response (Non-monetary Units) 



. Granted Units 
Supervision 



9. Content/Service Delivery 



10. Debit Units Request (Non-monetary Units) 



11. Rating 
Control 



12. Account 
Control 



13. Debit Units Response (Non-monetary Units) 



14. SIP Si :ssion released 



Figure 7.5: Event Charging with Reservation / Centralized Unit Determination and Centralized Rating 



SIP Session Establishment: the SIP session is established and the UE-A requests the desired content from the 
AS/MRFC. 

Reserve Units Request: depending on the service requested by the UE-A, the AS/MRFC selects the service 
identifier and forwards the Reserve Units Request to the ECF. 

Units Determination: the ECF determines the number of non-monetary units needed for the content/service 
delivery, based on the received service key. 

Rating Control: assisted by the rating entity the ECF calculates the number of monetary units that represent the 
price for the number of units determined in item 3. 

Account Control: the ECF checks whether the user's account balance is sufficient for the requested reservation. 

Reservation Control: if the user's account balance is sufficient, then the corresponding reservation is made. 

Reserve Units Response: the ECF informs the AS/MRFC of the reserved number of units. This includes the case 
where the number of units reserved indicates the permission to render the service that was identified by the 
received service key. Items 2 to 7 may be repeated several times. 

Granted Units Supervision: simultaneously with the service delivery, the AS/MRFC monitors the consumption of 
the reserved units. 
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9. Content/Service Delivery: the AS/MRFC delivers the content/service at once, in fractions or in individually 
chargeable items, corresponding to the reserved number of units. 

10. Debit Units Request: the AS/MRFC provides according to previous Reserve Units Response either the request to 
deduct of an amount corresponding to the consumed number of units from the subscriber's account, or solely the 
indication of whether the service was successfully delivered or not. In the case that no further units are required for 
this service, an appropriate indication triggering the release of the remaining reservation is given. 

11. Rating Control: assisted by the rating entity the ECF calculates the number of monetary units to deduct from the 
subscriber's account. 

12. Account Control: the ECF triggers the deduction of the calculated amount from the subscriber's account. 

13. Debit Units Response: the ECF informs the AS/MRFC of the actually deducted units. Items 10 to 13 may be 
repeated several times. 

14. SIP Session Released: the SIP session is released. 



7.3.3.2.3 



Decentralized Unit Determination and Decentralized Rating 



In the following scenario, the AS/MRFC request the ECF to assure the reservation of an amount of the specified 
number of monetary units from the subscriber's account. An account debit operation that triggers the deduction the 
amount from the subscriber's account is carried out following the conclusion of service delivery. 



ECF 
(SCCF, CPCF) 



1 . SIP Ses; ion established 



2. Units 
Determination 



X 



3. Rating Control 



4. Reserve Units Request {Monetary Units) 



5. Account 
Control 



6. Reservation 
Control 



7. Reserve Units Response {Monetary Units) 



8. Budget 
Control 



9. Content/Service Delivery 



10. Debit Units Request {Monetary Units) 



11. Account 
Control 



12. Debit Units Response (Monetary Units) 



13. SIP Si :ssion released 



Figure 7.6: Event Charging with Reservation / Centralized Unit Determination and Centralized Rating 
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1 . SIP Session Establishment: the SIP session is established and the UE-A requests the desired content from the 
AS/MRFC. 

2. Units Determination: depending on the service requested by the UE-A, the AS/MRFC determines the number of 
units accordingly. 

3. Rating Control: the AS/MRFC calculates the number of monetary units that represent the price for the number of 
units determined in item 2. 

4. Reserve Units Request: the AS/MRFC requests the ECF to assure the reservation of an amount corresponding to 
the calculated number of monetary units from the subscriber's account. 

5. Account Control: the ECF checks whether the user's account balance is sufficient for the requested reservation. 

6. Reservation Control: if the user's credit balance is sufficient, then the corresponding reservation is made. 

7. Reserve Units Response: the ECF informs the AS/MRFC of the reserved number of monetary units. Items 4 to 7 
may be repeated several times. 

8. Budget Control: simultaneously with the service delivery, the AS/MRFC monitors the consumption of the granted 
amount. 

9. Content/Service Delivery: the AS/MRFC delivers the content/service at once, in fractions or in individually 
chargeable items, corresponding to the number of units. 

10. Debit Units Request: the AS/MRFC requests the ECF to assure the deduction of an amount corresponding to the 
consumed number of monetary units from the subscriber's account. 

1 1 . Account Control: the ECF triggers the deduction of the consumed amount from the subscriber's account. 

12. Debit Units Response: the ECF indicates to the AS/MRFC the number of deducted monetary units. Items 10 to 12 
may be repeated several times. 

13. SIP Session Released: the SIP session is released. 



7.3.3.2.4 Further Options 

Multiple Debit Unit operations may relate to one Reserve Unit operation (n:l) and vice versa (l:n). More generally, 
multiple Debit Unit operations may relate to a different number of multiple Reserve Unit operations (n:m). After an 
initial Reserve Unit operation further Debit Unit and/or Reserve Unit operations may occur asynchronously from each 
others. 

7.4 Online Charging Event Collection 

7.4.1 Charging Event Creation 

7.4.1 .1 Online charging reference point IMS Network Entity - ECF (Ro) 

Event-based charging between an AS or MRFC and the ECF is performed using the Ro reference point. Ro is an open 
interface which is standardized in TS 32.225 [24]. The protocol for the Ro reference point is easily extendable to 
include additional online charging functions. The Ro reference point supports integrity protection and authentication for 
the case that the AS is outside the operator domain. 



8 Application Services 



Applications/services such as MMS and LCS are provided to the 3G subscribers via service nodes (which are outside 
the scope of the 3G core network). These servers (service nodes) responsible for the provision of an application services 
to a subscriber, can generate a service related CDR to record the details of the service transaction provided. The specific 
CDRs are defined in the specification TS 32.235 "Charging data description for application services" [17]. 
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8.1 Multimedia IVIessaging Service 



The Multimedia Messaging Service (MMS) charging description is based on the interface description in TS 23.140 
"Multimedia Messaging Service, Functional description, Stage 2 [19]. These MMS-CDRs are delivered by the MMS 
Relay/Server when receiving or delivering multimedia messages to the MMS User Agent or to another Multimedia 
Messaging Service Environment (MMSE). 

8.1.1 Charging Principles 
8.1.1.1 Charging Information 

Charging information for the usage of Multimedia Messaging Service is collected for each MS by the Multimedia 
Messaging Relay/Server (MMS R/S), which is serving that MMS User Agent. The information that the operator uses to 
generate an invoice to the subscriber is operator-specific. Billing aspects, e.g. a regular fee for a fixed period, are 
outside the scope of the present document. 

The MMS R/S collects charging information for each MS related with value-added service and the usage of MMS 
specific network resources. 

The MMS R/S shall collect the following charging information: 

usage of the MMS resources: the charging information shall describe the amount of data transmitted in MO and 
MT directions for the transfer of MM; 

storage duration: the storage duration of MM is counted as either (1) the time interval from the beginning of 
storage of the message until forwarding to another MMS R/S or as (2) the time interval from the beginning of 
storage until reception of the MM by an MMS User Agent. This is the time interval when a MM is saved on a 
non-volatile memory media; 

usage of the general Packet-Switched domain resources: the charging information shall describe the usage of 
other Packet-Switched domain-related resources; 

destination and source: the charging information shall provide the actual destination and source addresses used 
by the subscriber; 

usage of the external data networks: the charging information shall describe the amount of data sent and received 
to and from the external data network; 

the MMS R/S address: this provides the highest accuracy location information available. 



8.1 .2 Charging scenarios 



This subclause contains an example scenario illustrating the purpose and practical usage of the various types of records 
defined in the interface description [19]. The events triggering the generation of CDRs are events at the MMl reference 
point and/or events at the MM4 reference point. 
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8.1.2.1 



Originator and Recipient MMS Relay Server are the same 



Originator 
MMSUA 



MM1 submit.REQ 



MM1 submit.RES 



MM1_delivery_ report.REQ 



0-&R- 

MMS Relay/ 

Server 



MM1_read_reply_ originator.REQ 






MM1 notification. REQ 



IVIIVII notification. RES 



MIVI1 retrieve. REQ 



MM1 retrieve.RES 



IVIIVI1 _read_reply . REQ 



Recipient 
MMSUA 



IVIIVI1 _acl<nowledgement. REQ 



Figure 8.1 : Record trigger overview for combined case 



Table 8.1 : Record type overview for combined MMS Relay/Server 



Trigger point 


Trigger name 


1 


Qriginator MM1 Submission 


2 


Recipient IVIM1 Notification Request 


3 


Recipient IVIM1 Notification Response 


4 


Recipient IVIM1 Retrieval 


5 


Recipient MM1 Acknowledgement 


6 


Qriginator MM1 Delivery report 


7 


Recipient MMI Read reply Recipient 


8 


Qriginator MM4 Read reply originator 


Any time between 

1 ...8 

(see note) 


Qriginator MM Deletion 


NOTE: No CDR will be generated by receiving of MM1 User Agent initiated transactions 
(i.e. submit.REQ and IVIMI retrieve. REQ) 



£75/ 



3GPP TS 32.200 version 5.6.0 Release 5 



85 



ETSI TS 132 200 V5.6.0 (2004-03) 



8.1.2.2 



Originator and Recipient MMS Relay Server are not the same 



Originator 
IVIIVIS UA 



Originator 

IVIIVIS Relay/ 

Server 



MM1_submit.REQ 



MM1 submit. RE 
< { A1 




A4 )^ 



M M 1 _d e live ry_ ^^-^^ 
■^ report. i-icu T A5^ 



A6 )^ 



MM1_read_reply_ 
originator. REQ 




MM4_forward.REQ 



I\/II\/I4 forward. RES 



MI\/l4_delivery_report.REQ 



MM4_delivery_report.RES 



MM4_read_reply_report.REQ 



MM4_read_reply_re port. RES 



Recipient 

MMS Relay/ 

Server 



Recipient 
MMS UA 



^{ B1 



MMInotification. 
REQ 



MMInotification. 
RES 
B3^)^ 



MM1_retrieve.REQ 



MM1_acl<nowiedge 
B5 y^ ment.REQ 




MM1 retrieve. RES 

-^ ► 



MM 1 _read_reply_ 
recipient. REQ 

B8 ^y^ 




-^(,810 



Figure 8.2: Record trigger overview for distributed case 



Table 8.2: Trigger type overview for the Originator MMS Relay/Server 



Trigger point 


Trigger name 


A1 


Originator MM1 Submission 


A2 


Originator MM4 Forward Request 


A3 


Originator MM4 Forward Response 


A4 


Originator MM4 Delivery report 


A5 


Originator MM1 Delivery report 


A6 


Originator MM4 Read reply report 


A7 


Originator MM1 Read reply originator 


Any time between A1 ... A7 


Originator MM Deletion 
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Table 8.3: Trigger type overview for the Recipient IVIMS Relay/Server 



Trigger point 


Trigger name 


B1 


Recipient MIVI4 Forward 


B2 


Recipient IV1IV11 Notification Request 


B3 


Recipient IVIIVll Notification Response 


84 


Recipient IVIIVll Retrieval 


B5 


Recipient IVIMI Acknowledgement 


B6 


Recipient MIVI4 Delivery report Request 


87 


Recipient IVIM4 Delivery report Response 


B8 


Recipient IVIMI Read reply Recipient 


B9 


Recipient IVIIVI4 Read reply report Request 


810 


Recipient MM4 Read reply report Response 


Anytime after B1 


Recipient IVIM Deletion 



8.1.2.3 



MMBox management 















MMSUA 




MMS Relay/ 
Server 










MM1_upload. REQ 










MM1_upload. RES ^ 


s 


MM1_store. REQ 


MM1_store. RES ^ 


MM1 view. REQ 


MM1_view. RES ^ 


MM1_clelete. REQ 


MM1 delete. RES (^ 








J 





Figure 8.3: Record trigger overview for IVIMBox management 
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Table 8.4: Record type overview for MMBox management 



Trigger point 


Trigger name 


1 


MMBox MM1 Upload 


2 


MMBox MM1 Store 


3 


MMBox MM1 View 


4 


MMBox MM1 Delete 



8.1.2.4 



MMS VAS Applications 



VASP 



MM7 deliver. REQ 



MM7 deliver. RES 



MM7 submit. REQ 



MM7 submit. RES 



MM7_delivery_report. REQ 



MM7_delivery_report. RES 



MM74 submit. REQ 



MM7 submit. RES 



MM7_replace. REQ 



MM7_replace. RES 



MM7 cancel. REQ 



MM7 cancel. RES 



Originator 
MMSR/S 




1 





MM1 submit. REQ 



MM1 notification. REQ 



Figure 8.4: Record trigger overview for MMS VASP 
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Table 8.5: Record type overview for MMS VASP 



Trigger point 


Trigger name 


1 


MM7 Deliver Request 


2 


MM? Deliver Response 


3 


IV1M7 Submission 


4 


IV1M7 Delivery Report Request 


5 


IV1M7 Delivery Report Response 


6 


IV1M7 Submission 


7 


IV1M7 Replace 


8 


MM7 Cancel 
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